I have observed that it is impossible to unlock a session locked by kscreenlocker, since the tool required for password verification /sbin/unix_chkpwd is given inadequate permissions. Strangely, stage3 comes with properly configured unix_chkpwd, but re-emerging pam-1.5.2-r3 has the SUID bit stripped. Without the bit, password checking will always fail. Reproducible: Always Steps to Reproduce: 1. emerge sys-libs/pam 2. Lock your KDE plasma screen 3. Try to unlock with your password Actual Results: Unlocking fails in spite of correct password, no way to unlock the screen locker.
I came to think of *nix capabilities that might have or should have existed, and I found a kernel warning after my 4711 "fix": warning: `/sbin/unix_chkpwd' has both setuid-root and effective capabilities. Therefore not raising all capabilities. # getcap /sbin/unix_chkpwd /sbin/unix_chkpwd cap_dac_override=ep I am no expert in capabilities, you should understand that better.
The sys-libs/pam ebuild has this in pkg_postinst: > # The pam_unix module needs to check the password of the user which requires > # read access to /etc/shadow only. > fcaps cap_dac_override sbin/unix_chkpwd Are you certain that setting the setuid bit actually fixed your screen locker issue?
Also, please check your syslog for any messages that may have been logged when it failed to validate your password.
What a strange request, but here you are. What you see is my attempt to unlock the screen, and when it doesn't work, log in as root on TTY to change the password to a known status, and again try to login in the main session - which doesn't work. And chmod 4711 /sbin/unix_chkpwd really did the job, despite the confusing log entry. Jan 14 17:30:27 osiris unix_chkpwd[19295]: check pass; user unknown Jan 14 17:30:37 osiris su[19292]: pam_unix(su-l:session): session closed for user xx Jan 14 17:30:54 osiris unix_chkpwd[19318]: check pass; user unknown Jan 14 17:30:54 osiris unix_chkpwd[19318]: password check failed for user (xx) Jan 14 17:30:57 osiris unix_chkpwd[19325]: check pass; user unknown Jan 14 17:32:06 osiris passwd[20880]: password for 'xx' changed by 'root' Jan 14 17:32:11 osiris unix_chkpwd[21006]: check pass; user unknown Jan 14 17:32:14 osiris unix_chkpwd[21084]: check pass; user unknown Jan 14 17:33:11 osiris passwd[22207]: pam_unix(passwd:chauthtok): password changed for xx Jan 14 17:33:13 osiris login[19210]: pam_unix(login:session): session closed for user root Jan 14 17:33:13 osiris elogind-daemon[2669]: Removed session 4. Jan 14 17:33:18 osiris unix_chkpwd[22487]: check pass; user unknown Jan 14 17:33:18 osiris unix_chkpwd[22487]: password check failed for user (xx) Jan 14 17:33:18 osiris kscreenlocker_greet: pam_faillock(kde:auth): Consecutive login failures for user xx account temporarily locked
I'm just trying to figure out exactly where unix_chkpwd is failing. The log messages should help narrow that down.
I tried to reproduce this myself. With cap_dac_override on unix_chkpwd, unlocking a Plasma session works as expected. If I remove cap_dac_override from unix_chkpwd, I get errors similar to log you provided. > Jan 22 20:00:12 naomi unix_chkpwd[2906718]: check pass; user unknown > Jan 22 20:00:12 naomi unix_chkpwd[2906718]: password check failed for user (floppym) > Jan 22 20:00:12 naomi kscreenlocker_greet[2906691]: pam_unix(kde:auth): authentication failure; logname= uid=10000 euid=10000 tty= My best guess is that you have somehow configured your system in such a way that file capabilities are not working properly.
As a workaround, you could set USE="-filecaps" to install the unix_chkpwd binary as suid instead of with cap_dac_override. I don't really think it will be practical to diagnose your system via comments this bug report. If you want to debug it interactively, please reach out in #gentoo on the Libera.Chat IRC network,
