Bugzilla – Bug 944552
upgraded 13.2 x64 to 42.1 ms2 x64, logon of simple user with simple password ok, but lockscreen (idle) doesnt unlock ever again (password denied)
Last modified: 2015-09-06 12:20:13 UTC
coming from a 13.2 x64 install upgraded via .iso media to 42.1 milestone2 x64 my username is "testuser" and password is "test" this user existed on 13.2, system got upgraded to 42.1 so far so good, i can logon into the kd5 desktop and logoff and reboot then i went away from the machine and the lockscreen or screensaver fired up, and i couldnt unlock it again. first i thought i was having spelling problems but then i repro-d this behavior. from the normal kde5 desktop i can use the startmenu and the "Power / Session" submenu, and there the "lock" function, to reach this lockscreen i am talking about. this lockscreen is not accepting the string "test" to unlock my username "testuser". the logon screen (right after boot of 42.1) looks differently from this lockscreen though, i think it looks more like the 13.2 logon screen or exactly the same. so maybe some security complexity rules for passwords, or internal representations or some plug mechanism as to where the credentials are being looked up or something is wrong here. sorry for explaining this so awkwardly i am not a gui / desktop user of linux and therefore i am lacking all the exact terms and or defintions of these objects and things involved. anything else needed?
I tried another thing, I added from within the running 42.1 a second user named "testuse2" and its password "tes2" via yast2. it complained that the password is too simple but created the user and I can logon into kde5 with testuse2/tes2 just fine. But the lockscreen for this user is just blocked and eternally locked the same way as for testuser/test. I need to kill the while graphic stack with alt+backspace to get a new logon screen from scratch where both my users testuser/test and testuse2/tes2 work fine to login there.
Probably the same problem as in Bug#931296? There are two workarounds: - Check in /etc/pam.d/ whether you have *.rpmnew files (likely) and copy them over the corresponding common-xxx-pc files - chmod 4755 /usr/lib64/libexec/kcheckpass
Apparently I have lot of .rpmnew files for common-, but they are from 2013 testuser@linux-x64:/etc/pam.d> ls -lart common-* -rw-r--r-- 1 root root 448 Jun 25 2012 common-auth.pam-config-backup -rw-r--r-- 1 root root 378 Jun 25 2012 common-account.pam-config-backup -rw-r--r-- 1 root root 435 Jun 25 2012 common-session.pam-config-backup -rw-r--r-- 1 root root 855 Jun 25 2012 common-password.pam-config-backup lrwxrwxrwx 1 root root 17 Jul 11 2012 common-session -> common-session-pc lrwxrwxrwx 1 root root 18 Jul 11 2012 common-password -> common-password-pc lrwxrwxrwx 1 root root 14 Jul 11 2012 common-auth -> common-auth-pc lrwxrwxrwx 1 root root 17 Jul 11 2012 common-account -> common-account-pc -rw-r--r-- 1 root root 510 Sep 29 2013 common-password.rpmnew -rw-r--r-- 1 root root 462 Sep 29 2013 common-auth.rpmnew -rw-r--r-- 1 root root 392 Sep 29 2013 common-account.rpmnew -rw-r--r-- 1 root root 482 Sep 25 2014 common-session.rpmnew -rw-r--r-- 1 root root 557 Sep 4 19:27 common-auth-pc -rw-r--r-- 1 root root 446 Sep 4 19:27 common-account-pc -rw-r--r-- 1 root root 592 Sep 4 19:27 common-session-pc -rw-r--r-- 1 root root 474 Sep 4 19:27 common-password-pc I do wonder if these package updates of the various linux libraries and components can not write their settings more rigorously or create actually current files and only import old settings from previous versions of config files, so that there is not often these issues about .rpmnew and .rpmold conflicts. I still have not understood the mechanism or the actual idea behind all of this. Either newer versions of packages need new variables and settings in the config files or they don't. :(
I copied all the .rpmnew files over their respective normal filenames and the lock/unlock functionality of the Kde5 desktop can now unlock testuser/test normally. Thanks.
(In reply to andreas bittner from comment #3) > Apparently I have lot of .rpmnew files for common-, but they are from 2013 Yes, that's when openSUSE's default PAM config was changed to use pam_unix.so instead of the deprecated pam_unix2.so. > I do wonder if these package updates of the various linux libraries and > components can not write their settings more rigorously or create actually > current files and only import old settings from previous versions of config > files, so that there is not often these issues about .rpmnew and .rpmold > conflicts. The problem is that the user/administrator could change them to his likings/needs, and it would be a bad idea if that would be overwritten by updates. I do agree woth you though that we should find a solution (for those upgrading since versions before 13.1) that doesn't require manual intervention. One option would be to install kcheckpass as suid root (like it was done with KDE4), but that got rejected by the security team... > I still have not understood the mechanism or the actual idea behind all of > this. Either newer versions of packages need new variables and settings in > the config files or they don't. :( They don't. If they do the config files do get replaced ideally and the old ones saved as *.rpmsave. (In reply to andreas bittner from comment #4) > I copied all the .rpmnew files over their respective normal filenames and > the lock/unlock functionality of the Kde5 desktop can now unlock > testuser/test normally. Ok, so it is a duplicate. *** This bug has been marked as a duplicate of bug 931296 ***