/var/log/auth.log: Feb 8 11:54:31 userXX kcheckpass[9368]: pam_ecryptfs: pam_sm_authenticate: /home/userXX is already mounted Feb 8 11:54:31 userXX unix_chkpwd[9369]: check pass; user unknown Feb 8 11:54:31 userXX unix_chkpwd[9370]: check pass; user unknown Feb 8 11:54:31 userXX unix_chkpwd[9370]: password check failed for user (userXX) Feb 8 11:54:31 userXX kcheckpass[9368]: pam_unix(kdm:auth): authentication failure; logname= uid=1000 euid=1000 tty=:0 ruser= rhost= user=userXX Feb 8 11:54:31 userXX kcheckpass[9368]: pam_winbind(kdm:auth): getting password (0x00000388) Feb 8 11:54:31 userXX kcheckpass[9368]: pam_winbind(kdm:auth): pam_get_item returned a password Feb 8 11:54:31 userXX kcheckpass[9368]: pam_winbind(kdm:auth): request wbcLogonUser failed: WBC_ERR_AUTH_ERROR, PAM error: PAM_USER_UNKNOWN (10), NTSTATUS: NT_STATU S_NO_SUCH_USER, Error message was: No such user Feb 8 11:54:31 userXX kcheckpass[9368]: Authentication failure for userXX (invoked by uid 1000) Feb 8 11:54:35 userXX kcheckpass[9371]: pam_ecryptfs: pam_sm_authenticate: /home/userXX is already mounted Feb 8 11:54:35 userXX unix_chkpwd[9372]: check pass; user unknown Feb 8 11:54:35 userXX unix_chkpwd[9373]: check pass; user unknown Feb 8 11:54:35 userXX unix_chkpwd[9373]: password check failed for user (userXX) Reproducible: Always Steps to Reproduce: 1. lock screen 2. enter password 3. screen is not unlocked Actual Results: screen stays locked Expected Results: screen unlocked after applying this: sudo chmod 4755 /usr/lib/kde4/libexec/kcheckpass everything works alright again. so some update must have messed the permissions on this file
Assigning to correct product/component. If this bug is not against KDE 4.10, please reassign to locker component.
Yes, 4.10.0. Thanks.
This is most likely a configuration issue. Please ensure that kcheckpass is able to verify the password. E.g. it needs to be chown root and chmod u+s
This can be -- but need not to be a configuration issue. For my system opensuse 13.1, kde 4.14.4, kernel 3.19.0, swap 10G, ram 4G, I would say it's a timing issue, by uptime or by memory pressure, somewhere nested in the kscreenlocker and it's relation to the backend code. (PAM?) I'd get this issue after several succeeded resumes from hibernation when memory is filled, e.g. by firefox being up for several days. Without other issues. I've now made 23 successful consecutive resumes within 2d4h of uptime and it then showed up some significant behaviour: After submittig the password, for the instance of half of a second, there flashed up "Cannot unlock the session because the authentication system failed to work!" (login window) before passing to my session. This is the kind of a previous indicator, that the next or over-next resume may fail, with locking me out. Unfortunately, I've restarted firefox some hours ago, so it may again be 2 days for me to be able to reproduce this issue. I'll immediately provide you with specific logs, if you want them, just ask. From my point of view, there is nothing notable. If this is the wrong BUG for me to attach to, please, advise me! Best regards, Manuel Krause