Mailinglist Archive: opensuse-factory (498 mails)

< Previous Next >
Re: [opensuse-factory] solved: New Tumbleweed snapshot 20160514 released!


Am 2016-05-18 um 18:56 schrieb Wolfgang Bauer:
Am Mittwoch, 18. Mai 2016, 10:47:53 CEST schrieb Rainer Klier:
but screenlock did not work even after reverting my old pam config files.
then i downgraded all needed packages to use plasma5 screenlocker from
plasma 5.6.3.
the screenlock worked again.
then, just to try out, i again upgraded everything to plasma 5.6.4, and
then, to my surprise, it worked again... :-D

The kscreenlocker package will switch your PAM config to use pam_unix on every
installation (also updates).

ah, then this was responsible for the trouble.

As mentioned it does require pam_unix so that unlocking works correctly.
With pam_unix2, kscreenlocker_greet just doesn't have the necessary
permissions, making unlocking the session fail.

the strange thing is, that it works now, after i restored my pam config files (to versions which use pam_unix2), and reinstalled kscreenlocker.
so, why does this work now?

i just checked the files and they use pam_unix.so again but it still works, and now i am completely confused.... :-(


the chronology was:
1. updated pam and kscreenlocker with yast.
2. rebooted
3. could not login any more.
4. rebooted in maintenance mode and restored old pam config files. (using pam_unix2)
5. rebooted and logged in.
6. kscreenlocker didn't work any more.
7. tried different pam config files. without success.
8. restored old pam config files.
9. downgraded kscreenlocker to 5.6.3
10. rebooted and logged in.
11. old kscreenlocker works.
12. updated kscreenlocker with yast again to 5.6.4. (expecting to live without kscreenlocker)
13. tried kscreenlocker, but to my surprise, it worked.
14. i was assuming that pam config files are still the old ones, because everything is working.
15. checked pam config files, and noticed, that they are using pam_unix.so.


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.

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


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.

Just because your system is updated since 13.2 is not a good reason though,
mine is updated since 8.1 and still I am happily using pam_unix now... ;-)

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.

--
Best Regards | Freundliche Grüße | Cordialement | Cordiali Saluti |
*DI Rainer Klier*
Research & Development, Technical Sales Consultant

--
To unsubscribe, e-mail: opensuse-factory+unsubscribe@xxxxxxxxxxxx
To contact the owner, e-mail: opensuse-factory+owner@xxxxxxxxxxxx

< Previous Next >
Follow Ups