Scenario: - FreeBSD 12.4 latest - ports latest - Quite standard KDE with sddm setup Result: - After entering the password, it is necessary to press <ENTER> twice to actually unlock the screen. Expected result: - Pressing <ENTER> once should suffice to unlock the screen. Notes: - I believe this started happening after the upgrade from plasma 5.24.7 to 5.26. - It is still happening with the current plasma 5.27.3. -- Martin
(In reply to Martin Birgmeier from comment #0) > - After entering the password, it is necessary to press > <ENTER> twice to actually unlock the screen. Hmm. Not reproducible here with FreeBSD 14.0-CURRENT, % pkg iinfo security/plasma5-kscreenlocker plasma5-kscreenlocker-5.27.3_1 % uname -aKU FreeBSD mowa219-gjp4-8570p-freebsd 14.0-CURRENT FreeBSD 14.0-CURRENT #36 main-n261767-508aee968143: Sat Mar 25 23:33:05 GMT 2023 grahamperrin@mowa219-gjp4-8570p-freebsd:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 1400084 1400084 %
The user is in YP/NIS, not in master.passwd. Could this be the issue? Maybe together with unix-selfauth-helper? Admittedly, these are just wild guesses. -- Martin
(In reply to Martin Birgmeier from comment #2) I have no idea how NIS works internally (it's really not seen often nowadays), so could you please check first whether the helper is able to authenticate with NIS? Please check this while logged in as yourself: echo -n <password> | PAM_SM_FUNC=pam_sm_authenticate PAM_USER=<username> /usr/local/libexec/unix-selfauth-helper && echo ok If this doesn't print 'ok', my assumption would be that your PAM configuration uses an auth module next that doesn't reuse the first password....
Thank you for the support. This command prints "ok". -- Martin
(In reply to Martin Birgmeier from comment #4) Ok, that's "good" (so, the helper works as intended with NIS as well), but "bad" in this context because we need another idea what else could be wrong. Do you have any local modifications to /usr/local/etc/pam.d/kde or /etc/pam.d/system?
(In reply to Felix Palmen from comment #5) I do not think so: [0]# cat /usr/local/etc/pam.d/kde auth sufficient pam_exec.so return_prog_exit_status expose_authtok /usr/local/libexec/unix-selfauth-helper auth include system account include system [0]# cat /etc/pam.d/system # # $FreeBSD$ # # System-wide defaults # # auth auth sufficient pam_opie.so no_warn no_fake_prompts auth requisite pam_opieaccess.so no_warn allow_local #auth sufficient pam_krb5.so no_warn try_first_pass #auth sufficient pam_ssh.so no_warn try_first_pass auth required pam_unix.so no_warn try_first_pass nullok # account #account required pam_krb5.so account required pam_login_access.so account required pam_unix.so # session #session optional pam_ssh.so want_agent session required pam_lastlog.so no_fail # password #password sufficient pam_krb5.so no_warn try_first_pass password required pam_unix.so no_warn try_first_pass [0]# cat /etc/pam.d/kde cat: /etc/pam.d/kde: No such file or directory [1]#
(In reply to Martin Birgmeier from comment #6) Ok, then I'm out of ideas :( I see your pam_unix.so has "try_first_pass", so even *if* authentication using my selfauth-helper would go wrong, there should never be a second password prompt. I know "works for me" is not satisfactory at all, but ... it indeed works for me. Maybe somebody else might have *some* idea :/ It's a shot in the dark, but did you try to comment out all the opie stuff (in case you don't use it of course ...)?
Thank you for your support! I did not yet find the time to try your suggestions; if anything helps I will note it here. -- Martin
Removing the opie entries from pam.d/system did not change anything - it is still necessary to hit <RETURN> twice after entering the password. -- Martin
I also have this problem and it occurred after updating from 2022Q1 to 2022Q2 and thus with the update from kscreenlocker 5.24.7 to 5.27.3. With the kscreenlocker update to 5.26, kcheckpass was removed (which I believe was previously used on FreeBSD) and changed to pam. What also speaks for pam as the cause is that I have exactly the same problem with xscreensaver and a LXQT desktop. There kscreenlocker is not installed at all. In addition, the problem seems to exist only with 12.4, because on a 13.2 FreeBSD I do not have the problem.
2023Q1 and 2023Q2 was meant, of course.
As I can't reproduce such behavior, it's really hard to provide anything helpful ... Just another shot in the dark: Does /var/log/auth.log contain anything interesting when entering the password is requested twice?
Nothing comes up for me.
I changed no_warn to debug at auth pam_unix.so in the file /etc/pam.d/system and repeated the test. At the first enter nothing appears in /var/log/debug.log. At the second enter the following appears. kscreenlocker_greet[3701]: in openpam_dispatch(): calling pam_sm_setcred() in /usr/lib/pam_unix.so.6 kscreenlocker_greet[3701]: in openpam_dispatch(): /usr/lib/pam_unix.so.6: pam_sm_setcred(): Success
Created attachment 243371 [details] patch for pam_exec.c
Ok, found it. We need the following two commits for FreeBSD 12.4 as well, so unlocking on the first enter will work. https://cgit.freebsd.org/src/commit/lib/libpam/modules/pam_exec/pam_exec.c?h=stable/13&id=4d34b914d41cbe654035093e411c2ca68eb1ec82 https://cgit.freebsd.org/src/commit/lib/libpam/modules/pam_exec/pam_exec.c?h=stable/13&id=ea80848e1c0639e2ac8d3f974ddb9c6233491eb3 Enclosed a patch reduced to the most necessary.
12.4 is EOL, so this can be closed. Besides, nobody was willing to commit to 12-STABLE.