KDE 5.24.7 lockscreen didn´t allow unocking after a new install of KDE on FreeBSD13.1R. In my case I authenticate against Winbind but it should apply for all auth methods. I found the reason to be kcheckpass, which is used by the KDE lockscreen and expects /etc/pam.d/kde to exist. As it isn´t created by default, kcheckpass fails to verify any users and always returns a fail. So the login to KDE works but unlocking from lockscreen not. As a workaround (or possible fix..?) I softlinked (ln -s..) /etc/pam.d/kde to /etc/pam.d/system which let´s the lockscreen behave like the login screen and the rest of the system (as most users would expect it, I guess..). Anyway - at the moment the login screen is broken in the standard installation.
Hmm … I have lock and unlock working without /etc/pam.d/kde on 14.0-CURRENT % pkg provides /etc/pam.d/kde Name : pam_kde-1.0 Comment : PAM modules for KDE Display Manager Repo : FreeBSD Filename: usr/local/etc/pam.d/kde-np usr/local/etc/pam.d/kde % pkg info -x pam_kde pkg: No package(s) matching pam_kde % pkg provides kcheckpass Name : plasma5-kscreenlocker-5.24.7 Comment : Plasma5 secure lock screen architecture Repo : FreeBSD Filename: usr/local/lib/libexec/kcheckpass % pkg info -x plasma5-kscreenlocker plasma5-kscreenlocker-5.24.7 %
Locking and unlocking work for me too without /etc/pam.d/kde and /usr/local/etc/pam.d/kde. FreeBSD 13.1-RELEASE-p5, KDE 5.24.7.
Can confirm that. Created a local user "hund" that could unlock. Problem seems only to exist with non-local users -> AD/winbind in my case. Perhaps kcheckpass first tries /etc/passwd and PAM only after that? Would as well be a reason that the error wasn´t discovered earlier as it works in most cases...
(In reply to Christian Gutzler from comment #3) Moin moin With the current verison of plasma (>5.24), kcheckpass is no longer shipped and the pam-helper is used. Is this still an issue for you? mfg Tobias
Created attachment 241548 [details] skip segfaulting call to pam_setcred
Just some context. FreeBSD version is 13.1 libpam.so.6 apparently dies on signal 11 on the call to set_cred. From github following versons have this call. v5.27.4 v5.27.3 v5.27.2 v5.27.1 v5.27.0 v5.26.90 v5.26.5 v5.26.4 v5.26.3 v5.26.2 v5.26.1 v5.26.0 v5.25.90. I upgraded from plasma5-kscreenlocker-5.24.7 and got the issue: a non-unlocking lock screen. The patch works for me but the real error might be in libpam.so.6.
(In reply to Jesper Schmitz Mouridsen from comment #6) FreeBSD version is 13.1 libpam.so.6 apparently dies on signal 11 on the call to set_cred. See https://www.freebsd.org/security/advisories/FreeBSD-EN-22:19.pam_exec.asc
(In reply to Christian Gutzler from comment #0) > expects /etc/pam.d/kde to exist. As it isn´t created by default, kcheckpass > fails to verify any users and always returns a fail. Regarding this, hmmm: | pkg which /usr/local/etc/pam.d/kde | /usr/local/etc/pam.d/kde was installed by package plasma5-kscreenlocker-5.27.3_1 Yes, it's of course in etc below LOCALBASE, but that really shouldn't matter for PAM.
(In reply to Felix Palmen from comment #7) Thanks
After updating system to the latest HEAD and reinstalling all packages from scratch due to conflicts I also can no longer unlock the screen after locking. Open to ideas to try. # pkg which /usr/local/etc/pam.d/kde /usr/local/etc/pam.d/kde was installed by package plasma5-kscreenlocker-5.27.4_1
(In reply to Alexander Motin from comment #10) Possible things to analyze: Is something useful logged on auth errors (auth.log, maybe messages)? Does the content of /usr/local/etc/pam.d/kde look correct? It should just prepend unix-selfauth-helper and include "system", so, does /etc/pam.d/system look correct? Are you using a "normal" local account (one in the systems passwd db)? - If so, does unix-selfauth-helper work correctly when called standalone? As your user, execute > echo -n <password> | PAM_SM_FUNC=pam_sm_authenticate PAM_USER=<username> /usr/local/libexec/unix-selfauth-helper && echo ok This should print "ok" when given the correct credentials of your own user, nothing otherwise (also when trying a different user). - If not, does it work when you comment the line calling unix-selfauth-helper with pam_exec?
(In reply to Felix Palmen from comment #11) > Is something useful logged on auth errors (auth.log, maybe messages)? Nothing looks related to me. The only errors is auth.log seems unrelated: dbus-daemon[1401]: [system] Rejected send message, 2 matched rules; type="method_call", sender=":1.98" (uid=1001 pid=6443 comm="/usr/local/lib/libexec/org_kde_powerdevil") interface="org.freedeskto p.ConsoleKit.Manager" member="CanSuspendThenHibernate" error name="(unset)" requested_reply="0" destination="org.freedesktop.ConsoleKit" (uid=0 pid=1556 comm="/usr/local/sbin/console-kit-daemon --no-daemon") > Does the content of /usr/local/etc/pam.d/kde look correct? It should just prepend unix-selfauth-helper and include "system", so, does /etc/pam.d/system look correct? Look good to me, never touched them. > Are you using a "normal" local account (one in the systems passwd db)? Yes, simple boring stand-alone desktop system. > - If so, does unix-selfauth-helper work correctly when called standalone? As your user, execute > echo -n <password> | PAM_SM_FUNC=pam_sm_authenticate PAM_USER=<username> /usr/local/libexec/unix-selfauth-helper && echo ok This should print "ok" when given the correct credentials of your own user, nothing otherwise (also when trying a different user). Yes, it prints "ok". > - If not, does it work when you comment the line calling unix-selfauth-helper with pam_exec? Tried just in case -- no change, still can't unlock.
(In reply to Alexander Motin from comment #12) > Tried just in case -- no change, still can't unlock. That's expected of course ... unix-selfauth-helper(8) has a bit of explanation. Could try to rule out one other possible cause, by adding auth sufficient pam_permit.so to /usr/local/etc/pam.d/kde. When added after the line calling unix-selfauth-helper, it should allow unlocking with any password. When added as the first line, the screen locker shouldn't even ask for a password. If this *doesn't* work, it would mean /usr/local/etc/pam.d/kde isn't used... If it works, I'm out of ideas for now ... then something must be wrong either with pam_exec.so or with the screen locker itself.
(In reply to Felix Palmen from comment #13) > If this *doesn't* work, it would mean /usr/local/etc/pam.d/kde isn't used... Tried both before and after. It changed nothing -- the password is always asked and never accepted.
(In reply to Alexander Motin from comment #14) Ok, for some reason, it doesn't use that PAM service policy then. I have no idea why so far. Can you reproduce it in test-mode as well? Like: $ /usr/local/lib/libexec/kscreenlocker_greet --testing Just asking because that also works as expected for me (but on 13.2-RELEASE and plasma5-kscreenlocker-5.27.4_1)
(In reply to Felix Palmen from comment #15) The test mode reproduces it as well. It is actually much easier to test, since it does not lock me out each time, I can just close it. I don't know if it is relevant, but I see such messages when I run it: % /usr/local/lib/libexec/kscreenlocker_greet --testing QKqueueFileSystemWatcherEngine::addPaths: open: No such file or directory kf.kirigami: Failed to find a Kirigami platform plugin Locked at 1684356829 From possible differences: I run FreeBSD head of few days old and have two monitors (I have unlock prompt to each, but neither of two works now, previously worked both).
(In reply to Alexander Motin from comment #16) I have no idea what these messages are about :( I don't see any relevant changes recently to lib/libpam or contrib/openpam in base, and as pam_permit doesn't work for you either, it's pretty obvious the whole service policy file isn't found/used. Looking at the source of kscreenlocker, "kde" is clearly the default pam service name, so it doesn't make sense to me right now. Maybe tracing syscalls could shed some light. I just ran > truss /usr/local/lib/libexec/kscreenlocker_greet --testing 2>/tmp/locker.log and found this (as expected) in the log: > open("/etc/pam.d/kde",O_RDONLY,0666) ERR#2 'No such file or directory' > open("/etc/pam.conf",O_RDONLY,0666) ERR#2 'No such file or directory' > open("/usr/local/etc/pam.d/kde",O_RDONLY,0666) = 12 (0xc)
OK, at least for my case the mystery solved. My system was updated and cloned for decade(s) without a reinstall, and collected plenty of old files in /etc/pam.d/. KDE opened /etc/pam.d/kde by default before /usr/local/etc/pam.d/kde and failed after using it. Deletion of files older that last system update seems fixed the problem for me. Thanks for the hits. I wonder what should be the search order there.
(In reply to Alexander Motin from comment #18) This certainly explains it well and as there was no other comment for quite some time, I'll close this PR. OFC, anyone please request reopening it if you see the same issue and it's NOT caused by some "stray PAM files".