** Description changed: [Impact] unsquashfs does not preserve the stickybit when run as non-root (unlike other archive tools, like tar). While this is a bug in and of itself, it causes snaps with sticky directories to fail automated review because the requashed snap has the bit stripped and the resquashed snap as a result has a different checksum. The fix is to attempt the chmod with the stickybit and if it fails with EPERM when not root, try again without the stickybit. [Test Case] 1. create a squashfs with a sticky dir: $ mkdir -p /tmp/foo/sticky-dir $ chmod 1777 /tmp/foo/sticky-dir $ mksquashfs /tmp/foo test.squash -all-root 2. see that the squashfs has the sticky dir in the squash: $ unsquashfs -lls ./test.squash ... drwxrwxrwt root/root 3 2018-07-05 16:03 squashfs-root/sticky-dir 3. unsquash the squash as non-root: $ unsquashfs test.squash - 4. verified the stickybit is set: + 4. verify the stickybit is set: $ ls -ld squashfs-root/sticky-dir/ drwxrwxrwt 2 jamie jamie 4096 Jul 5 16:07 squashfs-root/sticky-dir/ Without the SRU, the directory is 0777 and the file 0775: $ ls -ld squashfs-root/sticky-dir/ drwxrwxrwx 2 jamie jamie 4096 Jul 5 16:07 squashfs-root/sticky-dir/ [Regression Potential] Due to the fallback behavior, the regression potential is considered low. Furthermore, because the non-root user is still the owner of the resulting unpacked sticky directories, there is no problem with being able to remove the unpacked directories on error, etc. [ Other Info ] In addition to the above, I've added test-squashfs-tools.py to QRT which verifies type, owner and permissions with mksquashfs and unsquashfs which fail for the sticky bit (but otherwise pass) when unpatched and pass when patched. [ Original description ] From https://sourceforge.net/p/squashfs/mailman/message/36343213/: "This set is an attempt to preserve the sticky bit when running unsquashfs as a non-root user. My main motivation for these changes is to improve reproducability when doing a sequence of "unsquashfs -> mksquashfs" as a non-root user but I think there's even more value in preserving the sticky bit in the case of a squashfs image containing a world-writable directory filled with files owned by a single user. Dropping the sticky bit could be considered to be a real bug in that scenario."
** Description changed: [Impact] unsquashfs does not preserve the stickybit when run as non-root (unlike other archive tools, like tar). While this is a bug in and of itself, it causes snaps with sticky directories to fail automated review because the requashed snap has the bit stripped and the resquashed snap as a result has a different checksum. The fix is to attempt the chmod with the stickybit and if it fails with EPERM when not root, try again without the stickybit. [Test Case] 1. create a squashfs with a sticky dir: $ mkdir -p /tmp/foo/sticky-dir $ chmod 1777 /tmp/foo/sticky-dir $ mksquashfs /tmp/foo test.squash -all-root 2. see that the squashfs has the sticky dir in the squash: $ unsquashfs -lls ./test.squash ... drwxrwxrwt root/root 3 2018-07-05 16:03 squashfs-root/sticky-dir 3. unsquash the squash as non-root: $ unsquashfs test.squash 4. verify the stickybit is set: $ ls -ld squashfs-root/sticky-dir/ drwxrwxrwt 2 jamie jamie 4096 Jul 5 16:07 squashfs-root/sticky-dir/ - Without the SRU, the directory is 0777 and the file 0775: + Without the SRU, the directory is 0777: $ ls -ld squashfs-root/sticky-dir/ drwxrwxrwx 2 jamie jamie 4096 Jul 5 16:07 squashfs-root/sticky-dir/ [Regression Potential] Due to the fallback behavior, the regression potential is considered low. Furthermore, because the non-root user is still the owner of the resulting unpacked sticky directories, there is no problem with being able to remove the unpacked directories on error, etc. [ Other Info ] In addition to the above, I've added test-squashfs-tools.py to QRT which verifies type, owner and permissions with mksquashfs and unsquashfs which fail for the sticky bit (but otherwise pass) when unpatched and pass when patched. [ Original description ] From https://sourceforge.net/p/squashfs/mailman/message/36343213/: "This set is an attempt to preserve the sticky bit when running unsquashfs as a non-root user. My main motivation for these changes is to improve reproducability when doing a sequence of "unsquashfs -> mksquashfs" as a non-root user but I think there's even more value in preserving the sticky bit in the case of a squashfs image containing a world-writable directory filled with files owned by a single user. Dropping the sticky bit could be considered to be a real bug in that scenario." ** Description changed: [Impact] unsquashfs does not preserve the stickybit when run as non-root (unlike other archive tools, like tar). While this is a bug in and of itself, it causes snaps with sticky directories to fail automated review because the requashed snap has the bit stripped and the resquashed snap as a result has a different checksum. The fix is to attempt the chmod with the stickybit and if it fails with EPERM when not root, try again without the stickybit. [Test Case] 1. create a squashfs with a sticky dir: $ mkdir -p /tmp/foo/sticky-dir $ chmod 1777 /tmp/foo/sticky-dir $ mksquashfs /tmp/foo test.squash -all-root 2. see that the squashfs has the sticky dir in the squash: $ unsquashfs -lls ./test.squash ... drwxrwxrwt root/root 3 2018-07-05 16:03 squashfs-root/sticky-dir 3. unsquash the squash as non-root: $ unsquashfs test.squash 4. verify the stickybit is set: $ ls -ld squashfs-root/sticky-dir/ drwxrwxrwt 2 jamie jamie 4096 Jul 5 16:07 squashfs-root/sticky-dir/ Without the SRU, the directory is 0777: $ ls -ld squashfs-root/sticky-dir/ drwxrwxrwx 2 jamie jamie 4096 Jul 5 16:07 squashfs-root/sticky-dir/ [Regression Potential] Due to the fallback behavior, the regression potential is considered low. Furthermore, because the non-root user is still the owner of the resulting unpacked sticky directories, there is no problem with being able to remove the unpacked directories on error, etc. [ Other Info ] - In addition to the above, I've added test-squashfs-tools.py to QRT which verifies type, owner and permissions with mksquashfs and unsquashfs which fail for the sticky bit (but otherwise pass) when unpatched and pass when patched. + In addition to the above, I've added test-squashfs-tools.py to QRT which verifies type, owner and permissions with mksquashfs and unsquashfs for many different entries. These fail for the sticky bit (but otherwise pass) when unpatched and pass when patched. [ Original description ] From https://sourceforge.net/p/squashfs/mailman/message/36343213/: "This set is an attempt to preserve the sticky bit when running unsquashfs as a non-root user. My main motivation for these changes is to improve reproducability when doing a sequence of "unsquashfs -> mksquashfs" as a non-root user but I think there's even more value in preserving the sticky bit in the case of a squashfs image containing a world-writable directory filled with files owned by a single user. Dropping the sticky bit could be considered to be a real bug in that scenario." -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1779914 Title: unsquashfs does not preserve sticky bit when run as non-root To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/squashfs-tools/+bug/1779914/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
