I lock my screen with ctrl+alt+L and unlocking fails even when the password is correct. The issue is that /sbin/unix_chkpwd was setuid earlier and it was able to read /etc/shadow file but after 1.2.1-r1 update, its not setuid but filecaps are used to relax the perms for /sbin/unix_chkpwd. As soon as I give /etc/shadow world read perm, it works, confirming the theory (the world perm is rolled back of course). The filecap does not work with squashfs as the strace of getcap shows: getxattr("/mnt/livecd/sbin/unix_chkpwd", "security.capability", 0x7ffed3b144a0, 20) = -1 EOPNOTSUPP (Operation not supported) Reproducible: Always Steps to Reproduce: 1. Lock the screen 2. Unlock the screen with correct password 3. Actual Results: Can't unlock. Expected Results: Should unlock
extended attributes are enabled on squashfs but squashfs does not support the security capability.
Please attach the build log for pam-1.2.1-r1 so we can see if the fcaps function detected that squashfs doesn't support the capability.
your strace shows the livecd. are you actually running a livecd here ? did you build your own ? are you doing something else weird ? when you file bugs, please provide full details about your environment.
> your strace shows the livecd. I think I mentioned squashfs. The build does not happen on a squashfs filesystem (which is read-only as you might know). Build happens on a ext4 FS. squashfs is the runtime rootfs FS just like livecd (there are symlinks in / going to /mnt/livecd). Basically, I have a single image setup, where I build a single squashfs image on my most powerful box using portage, and this image boots on about a couple dozen PCs/laptops. So, basically, the rootfs is mostly a pointer to a squashfs read-only FS (/sbin is a symlink to /mnt/livecd/sbin e.g). The /home is mounted either using ext4 or ZFS, and that's where all my writes go to. I regularly update the image on the powerful box using portage without affecting any of my PCs/laptops. Once I figure I need to update to latest image (security issues or a kernel feature I need), I pick a victim PC/laptop, and test the latest image there. If it all passes, all my systems get the new image and pick it up on their next reboot, whenever that happens. There is a way to restore to the older image if a PC/laptop fails certain functionality. This way of working has served me well. I don't need to build on all boxes, and I do not suffer outage on each and every machine randomly because of unstable packages. This bug was found on one of those victim runs....:-) I downgraded to 1.2.1 for now.
Why would you close the bug now? Give me at least some time to provide you info. I mentioned not all filesystems (with an example of squashfs) support filecaps. Isn't that information enough to rethink the patch added in -r1?
(In reply to devsk from comment #4) you mentioned squashfs, but you didn't mention the livecd. i know how it's used beyond just the livecd -- i've done plenty of embedded development myself. the difference is that the livecd environment *we* control and can fix whereas squashfs images *you* create are your responsibility. in this case, if you're building your own squashfs image and you aren't enabling the correct kernel configs or filesystem settings for the USE flag settings you're using (in this case USE=fcaps but you didn't enable SQUASHFS_XATTR or you generated the squashfs using -no-xattrs), then that is an error in your setup. you're responsible for making sure your kernel/fs are properly configured based on the USE flag settings chosen. (In reply to devsk from comment #5) the bug status is pretty clear: you needed to provide info. not everyone comes back with info. and no, i see no reason to rethink the changes made to the -r2 ebuild.
I mentioned this also: >> extended attributes are enabled on squashfs but >> squashfs does not support the security capability. $ zgrep SQUASHFS /proc/config.gz CONFIG_SQUASHFS=y # CONFIG_SQUASHFS_FILE_CACHE is not set CONFIG_SQUASHFS_FILE_DIRECT=y # CONFIG_SQUASHFS_DECOMP_SINGLE is not set # CONFIG_SQUASHFS_DECOMP_MULTI is not set CONFIG_SQUASHFS_DECOMP_MULTI_PERCPU=y CONFIG_SQUASHFS_XATTR=y CONFIG_SQUASHFS_ZLIB=y CONFIG_SQUASHFS_LZ4=y CONFIG_SQUASHFS_LZO=y CONFIG_SQUASHFS_XZ=y CONFIG_SQUASHFS_4K_DEVBLK_SIZE=y CONFIG_SQUASHFS_EMBEDDED=y CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=100 The command has no reference to -no-xattrs: mksquashfs source/ $livecdHome/target/x86.squ -comp gzip -b 262144 > the livecd environment *we* control and can fix your livecd env is broken, please try and see for yourself. BTW, I am a developer myself.
(In reply to devsk from comment #7) you created the squashfs hence you're responsible for making sure things work. that means if fcaps doesn't work for you, then you have to disable the flag. there is no error in the ebuilds or eclasses here -- the settings were applied correctly when they were installed the ext4 fs. it's like saying "i copied the files to a VFAT and it lost ownership information".
I didn't realize that the eclass does the setuid when filecaps is disabled. My bad! I just went by the change in the ebuild. Sorry about that!
(In reply to devsk from comment #9) no worries. please let us know if you do find a way to get xattrs working for you with squashfs. afaik, it should.
