Hello, I was debugging an issue that was happening when my 'cinnamon-screensaver' application locked my session after the default 15 minute period. Every time I tried to unlock my system with the correct password, the screensaver would say "incorrect password". Looking at 'journalctl', I noticed the following: Apr 14 02:30:02 bethany cinnamon-screensaver-pam-helper[3876]: gkr-pam: no password is available for user Apr 14 02:30:02 bethany cinnamon-screensaver-pam-helper[3876]: pam_unix(cinnamon-screensaver:auth): auth could not identify password for [jon] Apr 14 02:30:02 bethany cinnamon-screensaver-pam-helper[3876]: pam_unix(cinnamon-screensaver:auth): conversation failed Also when I try to change the user password in the cinnamon settings, the "current password" also fails to be verified because of the following/similar error: Apr 14 03:17:17 bethany python2.7[24405]: pam_unix(passwd:auth): auth could not identify password for [jon] Apr 14 03:17:17 bethany python2.7[24405]: pam_unix(passwd:auth): conversation failed After researching, I found the following link: https://robsworldoftech.blogspot.com/2014/08/debianubuntulinux-mint-screensaver.html#! It explains that the /sbin/unix_chkpwd needs to be either suid or sgid in order to have the permissions necessary to read the /etc/shadow file (Which is root:root 640). Doing: chmod u+s /sbin/unix_chkpwd allowed cinnamon-screensaver to properly unlock the session. I still cannot change my password via cinnamon settings but I believe the errors are related. Should we be setting suid on /sbin/unix_chkpwd for all of our stage3s by default?
Also, I extracted the stage3-amd64-systemd-20180408.tar.bz2 as root with "tar xpf <file>" in order to verify this. A fellow gentoo user verified that the CONTENTS file for the regular amd64 (non systemd stage3) contains the u+s properly. I downloaded the regular amd64 stage3 to verify this and it indeed contains the value properly. Which leads me to believe that maybe there are more images apart from the amd64 systemd image that don't have this value set..
Adding in that "ping" and "arping" are also two applications that have u+s on default amd64 stage3, but not in default amd64 systemd stage3. We should look at all of the u+s on all of the images and make sure everything is identical across all of the images.
I attempted to re-extract the image with: tar xpf stage3-amd64-systemd-20180408.tar.bz2 --xattrs-include='*.*' --numeric-owner rather than just xpf, but it still didn't have it. I believe this covers all of the basis I can think off regarding default permissions.
(In reply to Jonathan Vasquez from comment #3) > I attempted to re-extract the image with: > > tar xpf stage3-amd64-systemd-20180408.tar.bz2 --xattrs-include='*.*' > --numeric-owner > > rather than just xpf, but it still didn't have it. I believe this covers all > of the basis I can think off regarding default permissions. We've been moving away from suid to filecaps. So, in sys-libs/pam ebuilds we have fcaps cap_dac_override sbin/unix_chkpwd Similarly in net-misc/iputils fcaps cap_net_raw \ bin/ping \ $(usex arping 'bin/arping' '') \ $(usex clockdiff 'usr/bin/clockdiff' '') I just checked the stage3 root on the build machine and I'm getting # pwd ; getcap -v sbin/unix_chkpwd /var/tmp/catalyst/tmp/systemd/amd64/stage3-amd64-systemd-20180413 sbin/unix_chkpwd = cap_dac_override+ep so it seems the filecaps was set there. Can you check if it survives in the tarball. I'm ccing Jorge who probably can shed light on what's going on.
(In reply to Anthony Basile from comment #4) > (In reply to Jonathan Vasquez from comment #3) > > I attempted to re-extract the image with: > > > > tar xpf stage3-amd64-systemd-20180408.tar.bz2 --xattrs-include='*.*' > > --numeric-owner > > > > rather than just xpf, but it still didn't have it. I believe this covers all > > of the basis I can think off regarding default permissions. > > We've been moving away from suid to filecaps. So, in sys-libs/pam ebuilds > we have > > fcaps cap_dac_override sbin/unix_chkpwd > > Similarly in net-misc/iputils > > fcaps cap_net_raw \ > bin/ping \ > $(usex arping 'bin/arping' '') \ > $(usex clockdiff 'usr/bin/clockdiff' '') > We've decided to disable caps on stages for now (non systemd stages), as they require users to unpack them with the correct tar options or the markings are lost. Have you tried using tar --xattrs --xattrs-include=security.capability --xattrs-include=user.pax.flags --selinux ? > I just checked the stage3 root on the build machine and I'm getting > > # pwd ; getcap -v sbin/unix_chkpwd > /var/tmp/catalyst/tmp/systemd/amd64/stage3-amd64-systemd-20180413 > sbin/unix_chkpwd = cap_dac_override+ep > > so it seems the filecaps was set there. Can you check if it survives in the > tarball. > > I'm ccing Jorge who probably can shed light on what's going on. What catalyst version are you using to build the stages? IIRC, the changes for caps have been present on catalyst for 2 or 3 years.
It seems like over the years the instructions for extracting the stage3 are slowly getting more complicated (Including the default instructions in the handbook). If we could try to keep it to simply "tar xpf", that would be easier for everyone trying to install the stage.
(In reply to Jonathan Vasquez from comment #6) > It seems like over the years the instructions for extracting the stage3 are > slowly getting more complicated (Including the default instructions in the > handbook). If we could try to keep it to simply "tar xpf", that would be > easier for everyone trying to install the stage. The instructions didn't become more complicated "on purpose". The problem is that tar upstream hasn't added to the defaults the adding and extracting of filiecaps. This is why the non-systemd stages are being built without filecaps.
Haha Jorge, I know they weren't made more complicated on purpose. I just wanted to mention that we should keep that in mind :).
> > What catalyst version are you using to build the stages? IIRC, the changes > for caps have been present on catalyst for 2 or 3 years. I'm using 2.0.18-r4 > The instructions didn't become more complicated "on purpose". The problem is > that tar upstream hasn't added to the defaults the adding and extracting of > filiecaps. > This is why the non-systemd stages are being built without filecaps. I tried to get upstream to take this issue seriously but was ignored. In particular, I was worried about PaX markings (which I helped migrate to file system extended attributes), and suggested tar have a simple way of recording all xattr namespaces, but to no avail. Jorge, would you suggest I set -filecaps for systemd like you do on the regular stage3's? I assume that choice is orthogonal to anything systemd requires.
(In reply to Anthony Basile from comment #9) > > > > What catalyst version are you using to build the stages? IIRC, the changes > > for caps have been present on catalyst for 2 or 3 years. > > I'm using 2.0.18-r4 I believe that might be the source of the problem. Please use the latest catalyst-3. > > The instructions didn't become more complicated "on purpose". The problem is > > that tar upstream hasn't added to the defaults the adding and extracting of > > filiecaps. > > This is why the non-systemd stages are being built without filecaps. > > I tried to get upstream to take this issue seriously but was ignored. In > particular, I was worried about PaX markings (which I helped migrate to file > system extended attributes), and suggested tar have a simple way of > recording all xattr namespaces, but to no avail. > > > Jorge, would you suggest I set -filecaps for systemd like you do on the > regular stage3's? I assume that choice is orthogonal to anything systemd > requires. I think it should be. Applying it should also solve the issue without needing to update catalyst. In any case, I'd suggest updating catalyst and that you decide whether you want to promote the use of filecaps or not. For the record, I do prefer using filecaps, I just gave up on the default stages for the extra work required by the users. With time and user experience, it might be easier to switch to filecaps.
When the new versions land, can you please test to make sure this is fixed and close this bug.
(In reply to Anthony Basile from comment #11) > When the new versions land, can you please test to make sure this is fixed > and close this bug. okay no response. the last i checked, /sbin/unix_chkpwd had setsuid set with the changes i implemented. re-open this bug if this is still an issue.
Hey Anthony, I just got a chance to download new tarball and test it out, I did the following and the markings are now appearing in the following files in the tarball (for /bin and /sbin): /bin/arping /bin/mount /bin/passwd /bin/ping /bin/su /bin/umount /sbin/unix_chkpwd tar xpf stage3-amd64-systemd-20180428.tar.bz2 Thanks for the change! - Jonathan
