Am Donnerstag, 19. Mai 2016, 10:48:55 schrieb Rainer Klier:
the chronology was: 1. updated pam and kscreenlocker with yast.
Why with YaST? And what packages exactly? Maybe there was some mixture of packages then. pam_unix2 is part of pam- modules, not pam itself (unlike pam_unix). Might have been caused by the order in which you installed the packages too, though.
2. rebooted 3. could not login any more. 4. rebooted in maintenance mode and restored old pam config files.
What do you mean with "maintenance mode"? Booting to recovery mode should not have any influence on the PAM config. I.e. if the PAM config was broken (causing you not to be able to login), booting to recovery mode won't fix it. Or do you mean you logged in in text mode?
(using pam_unix2) 5. rebooted and logged in. 6. kscreenlocker didn't work any more.
That's to be expected as explained, and the reason why we added this "workaround" to enforce pam_unix in the first place. As mentioned, if using pam_unix2, you need to make kcheckpass suid root for unlocking to work.
A workaround is to make /usr/lib64/libexec/kcheckpass suid root, that should prevent such problems in the future. Updates will change the file permissions again of course, so you should rather add an entry to /etc/permissions.local and run chkstat to apply it. i know this since 2015-09-24. i discussed this in these days in this list under the subject "tumbleweed update 2015-09-24 unlock screensaver failed".
it was you who helped me in this thread.
I vaguely remember that thread, but not the details. But that was before we added the forced PAM change to pam_unix to the Plasma packages (which was done on 2015-10-23, a month later). At that point, pam_unix2 was not changed to pam_unix automatically, causing the screenlocker to fail on upgraded systems (pam_unix is the default since 12.3 IIRC, but that only affects new installations).
If you want to prevent your PAM config from being changed, convert the symlinks common-session and so on to proper files, pam-config should not touch them any more then.
ah, because of thread "tumbleweed update 2015-09-24 unlock screensaver failed" i have it this way since 2015-09-24: common-account -> common-account-pc common-auth -> common-auth-pc common-password -> common-password-pc common-session -> common-session-pc
so, you suggest to remove the links and make normal files? so, copy the *-pc files over the appropriate links? so that afterwards i simply have: common-account common-auth common-password common-session
Basically yes. pam-config only modifies the common-xxx-pc files, but the actual config is read from common-xxx. If the latter are not symlinks to common-xxx-pc, the actual config will not be changed automatically (and pam-config will even bail out if it notices this). But again, this is only necessary if you have some custom PAM configuration that you don't want to be changed automatically.
But if you don't have a very specific need to use pam_unix2, it's probably easier to just stick to pam_unix.
i thought, i can't do this.
i assumed this by interpreting your answers in the "tumbleweed update 2015-09-24 unlock screensaver failed" thread. so maybe i misinterpreted your answers. because to my surprise it works now.
As I wrote, back then the PAM config was not changed to pam_unix automatically. So you had to either change it manually or make kcheckpass suid root (which should still work even with pam_unix, but should not be necessary in that case).
ok, it seems, that my system also works now with pam_unix.
but now i completely don't know WHY i could not login after updating pam and kscreenlocker.... and WHY it all works now after reinstalling kscreenlocker.
Well, I can only suppose something got messed up in the (automatically generated) PAM config somehow then (reinstalling kscreenlocker will regenerate the config). But I cannot tell you what and why. Kind Regards, Wolfgang -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org