.Xscreensaver does not accept password

statikregimen

Hi all,

Seems this is a rare problem, but I've found some other, much older posts with similar issues.Most of the solutions didn't work/apply. This is the 3rd machine I've set up recently with Gentoo, and the other two (last I checked) are working normally with default configs/use flags. However, on this one I had to build xscreensaver without pam support which has resolved the issue for now. Is this in any way suboptimal for local security? It certainly does not seem ideal for new users who generally expect things to work out of the box.

With that, I was hoping somebody might be able to provide some insight on other things I can look at, since this is a fresh install presumably configured identically to the other machines I've done Perhaps I overlooked something in my configs, or I've found a bug and should report? If the later, how to narrow down where the bug lies (in pam, xscreensaver, something else)?

Any guidance is appreciated!

Cheers.

JWJones · n00b Joined: 11 Jan 2015 Posts: 19 Location: Oregon

I've had this happen to me before, too. I was unable to resolve it (PAM was not involved, however, as I recall), so I simply gave up on xscreensaver altogether and went minimal with slock for screen locking, avoiding screensavers.

Sorry, but I don't really remember any specifics beyond that.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21586

What does xscreensaver log when the unlock fails? I have seen this when it is configured to use PAM and it is unable to load PAM. I have also seen this when it is run with the no-new-privs restriction set, since it needs a privileged helper to verify the password.

statikregimen · Posted: Fri Mar 30, 2018 1:35 pm Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21586

statikregimen · Posted: Sat Mar 31, 2018 1:53 am Post subject:

JWJones · n00b Joined: 11 Jan 2015 Posts: 19 Location: Oregon

Yes, slock, not stock, which can be started after a specific period of user inactivity using xautolock. More info here:

https://tools.suckless.org/slock/

statikregimen · Posted: Mon Apr 02, 2018 3:14 pm Post subject:

Thanks, JWJones - I'll definitely switch to sLock for my mobile machines where eye candy is not useful

Also, just finished setting up another machine. It is also having the same issue. It occurred to me that my working systems have not been updated in several days (i.e. since before these 2 new installs) So I'll update those, and see if the problem appears. If so, I'd say that's a strong indicator of a bug somewhere, rather than anything I'm doing wrong (but pro-tip: it's probably me lol).

Cheers

Hu · Moderator Joined: 06 Mar 2007 Posts: 21586

statikregimen · Posted: Tue Apr 03, 2018 1:30 pm Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21586

According to equery belongs, that file is owned by sys-libs/pam. On an affected machine, what is the output of cat -n /var/db/pkg/sys-libs/pam-*/FEATURES? What version of pam is in use? What is the output of emerge --info?

statikregimen · Posted: Wed Apr 04, 2018 3:24 am Post subject:

ct85711 · Veteran Joined: 27 Sep 2005 Posts: 1791

I know when I checked on my system, unix_chkpwd came up with permissions as 0711. I can't really say if xscreensaver locking works or not for my system, as I don't use that side. What would be interesting, is finding out if that file defaults as 0711 when pam is installed or was it possibly changed in a earlier version or changed by some other package.

I may just do a little test on my system, by intentionally breaking the system and removing pam; and reinstall it and see what the permissions of that file is
Note: I am fully aware, in doing so I get to pick up all pieces; and DO NOT recommend anyone do the same thing without knowing exactly what they are doing.

Update:
Well, I confirmed for my system at least, unix_chkpwd comes by default with permissions of 0711 only. This was tested, but completely remove pam from system and verify the file is gone; then freshly recompiling pam again and rechecking the file's permissions.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21586

ct85711, thank you for prompting me to look more closely. If sys-libs/pam is built with USE=filecaps, it can install a mode 711 unix_chkpwd and rely on file capabilities to grant CAP_DAC_OVERRIDE. If built without file caps, unix_chkpwd must be 4711 so that it gets CAP_DAC_OVERRIDE (and many other unnecessary capabilities) as a result of being suid root. So if the OP had built with USE=filecaps, then telling him to enable suid was wrong. OP: what is the output of emerge --pretend --verbose sys-libs/pam?

statikregimen · Posted: Thu Apr 05, 2018 3:41 pm Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21586

My advice may have worked, but since you have USE=filecaps, my advice was the wrong solution. We need to determine whether unix_chkpwd had the file capability annotation. If it did, we need to know why it did not work for you. If it did not, we need to know why it did not, since USE=filecaps should have caused it to be there. If you re-emerge sys-libs/pam, keeping USE=filecaps, what is the output of ls -l /sbin/unix_chkpwd ; getcap /sbin/unix_chkpwd? How did you install PAM previously? Was this system created using only Portage to install files or were some files installed through other means, such as cp -r from some other source?

statikregimen · Posted: Fri Apr 06, 2018 3:03 am Post subject:

Hu · Moderator Joined: 06 Mar 2007 Posts: 21586

Something is strange here. If you have USE=filecaps, your file should not be suid, and should have a file capability. Your older output says you have USE=filecaps. Your most recent post says you have suid. You did not show getcap. Please show that, and add -v so that it prints even if there are no capabilities.

Yes, pam is a dependency. I wanted to know if this system had been installed through Portage or had been copied from a working Gentoo install. The latter might, depending on options used, lose file capabilities.

statikregimen · Posted: Sun Apr 08, 2018 3:42 pm Post subject:

wtf...? I swear I copied/pasted the command you were looking for...

Hu · Moderator Joined: 06 Mar 2007 Posts: 21586

I wanted -v on getcap, not on ls. However, the error message you received is good enough. There is no need to provide getcap -v now. I interpret that error message to mean that your filesystem does not support file capabilities. What type of filesystem did you use for the /sbin directory? What mount options are set for it?

Regarding USE=filecaps vs suid: if you build the package with USE=filecaps, then unix_chkpwd should not be suid and should have a file capability annotation. If you build with USE=-filecaps, then unix_chkpwd should be suid. In your most recent post where you showed the USE flags, you have USE=filecaps, so I would expect you not to have the suid flag on unix_chkpwd. However, your most recent post where you showed permissions shows that unix_chkpwd is suid. So either you set it manually, per my (now known to be incorrect) advice earlier in the thread, or something else strange is happening.

statikregimen · Posted: Wed Apr 11, 2018 2:12 pm Post subject:

Sorry for the delayed response. I use ext4 for everything

I did in fact change the permissions per your original suggestion prior to learning that it was not the proper solution. I'm not sure how to undo it. I need to educate myself quite a bit more on this stuff.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21586

pablo_supertux · Posted: Fri Mar 26, 2021 10:33 am Post subject:

Hi

sorry to revive such an old thread, but I'm dealing with exact the same issue here.

neither xscreensaver nor mate-screensaver did accept my password, on the log files, I also got

Hu · Moderator Joined: 06 Mar 2007 Posts: 21586

For me, unix_chkpwd is mode 711 and the getcap output is:

pablo_supertux · Posted: Fri Mar 26, 2021 5:35 pm Post subject: