SUMMARY *** kscreenlocker_greet will not allow further unlock attempts when wrong password is entered even once. One has to kill the process and unlock the session from text TTY. When the correct password is entered on the first try, no issue is observed. When the wrong password is entered, the black "dots" that indicate typed characters don't disappear from the input field. The reveal button works, showing the typed characters but even after ensuring the correct password is entered, the screen is not unlocked. Moreover, when moving the currsor to second monitor, another empty input and background wallpaper appears, as in the new greeter has been started (ps output confirms that two instances of the greeter are present at the time), and I can type the password there but even correct one doesn't unlock the screen. I have this behavrior since plasma (probably before) 5.26.x, now on the 6.0 it is the same. Also no indication about wrong password is displayed. *** STEPS TO REPRODUCE 1. lock the screen 2. type wrong password and submit 3. type correct password and submit OBSERVED RESULT kscreenlocker_greet does not show any indication about entering the wrong password and does not clean input field. another process of kscreenlocker_greet is started along the original one. User is unable to unlock the screen using neither process/input and has to kill the locker process from text tty and do loginctl unlock-session manually. EXPECTED RESULT upon entering invalid password, some indication is presented to the user and user can try again after some grace period, and if typing correct password, the screen will be unlocked without the need to change to the tty and kill the process by hand. SOFTWARE/OS VERSIONS Windows: n/a macOS: n/a Linux/KDE Plasma: nixOs 24.05 (unstable branch) (available in About System) KDE Plasma Version: 5.26.1-6.0.0 KDE Frameworks Version: 5.26.1-6.0.0 Qt Version: 5.x.x-6.6.2 ADDITIONAL INFORMATION I didn't write down the Qt version on plasma5 and didn't write down the first plasma5 version where thsi was occuring for me. It might have been before 5.26 but this is the first one I've written down. Today I switched to plasma6 thanks to the availability in nixOs and the behavior is identical. In the journal I see only something like this currently on plasma6: Feb 29 14:35:56 nixos kscreenlocker_greet[7863]: pam_warn(kde-fingerprint:auth): function=[pam_sm_authenticate] flags=0 service=[kde-fingerprint] terminal=[<unknown>] user=[<REDACTED>] ruser=[<unknown>] rhost=[<unknown>] Feb 29 14:35:56 nixos kscreenlocker_greet[7863]: pam_warn(kde-smartcard:auth): function=[pam_sm_authenticate] flags=0 service=[kde-smartcard] terminal=[<unknown>] user=[<REDACTED>] ruser=[<unknown>] rhost=[<unknown>] Feb 29 14:35:58 nixos unix_chkpwd[7927]: password check failed for user (<REDACTED>) Feb 29 14:35:58 nixos kscreenlocker_greet[7863]: pam_unix(kde:auth): authentication failure; logname=<REDACTED> uid=1000 euid=1000 tty= ruser= rhost= user=<REDACTED> Feb 29 14:35:58 nixos kscreenlocker_greet[7863]: pam_kwallet5(kde:auth): pam_kwallet5: pam_sm_authenticate Feb 29 14:35:58 nixos kscreenlocker_greet[7863]: pam_kwallet5(kde:auth): pam_kwallet5: we were already executed Feb 29 14:35:58 nixos unix_chkpwd[7928]: password check failed for user (<REDACTED>) Feb 29 14:35:58 nixos kscreenlocker_greet[7863]: pam_krb5(kde:auth): authentication failure; logname=<REDACTED> uid=1000 euid=1000 tty= ruser= rhost= Feb 29 14:35:58 nixos kscreenlocker_greet[7929]: pam_ccreds: launching helper binary Feb 29 14:35:58 nixos kscreenlocker_greet[7929]: pam_ccreds: helper binary is not available Feb 29 14:35:58 nixos kscreenlocker_greet[7929]: QObject::killTimer: Timers cannot be stopped from another thread Feb 29 14:35:58 nixos kscreenlocker_greet[7929]: QObject::~QObject: Timers cannot be stopped from another thread
This is a PAM restriction set by your distro, which the screen locker honors. I'd recommend reporting it to the NixOS folks.
(In reply to Nate Graham from comment #1) > This is a PAM restriction set by your distro, which the screen locker > honors. I'd recommend reporting it to the NixOS folks. Can you provide a little more details? What is the restriction? The number of unlock attempts? I will take this to nixOs but I need to know a bit more. Shouldn't this restriction be somehow communicated to the user? How am I supposed to know at unlock screen that I will never get another attempt? Currently this feels more broken than intentional.
Details can be found at: https://linux.die.net/man/8/pam_faillock Yes it would definitely be nice if this would be communicated better. We need a replacement for PAM that isn't from the 80s and designed for text terminals, which is a bigger task bigger than a bugzilla ticket.
How can I verify that this is in fact the RC? I grepped through all of my pam.d files and the faillock is required only on the pam.d/su which I doubt is used here. login, xscreensaver, xlock, vlock, i3lock nor any of sddm* files in pam.d don't mention the failllock. Any other module could be the culprit here?
I think this is not related to faillock but to krb5. I disabled the krb5 support on my system, which as a side effect also disables pam/krb5 module, and now the lock screen works as expected. I get the notification of incorrect password right away and after grace period I am able to try again and it unlocks if another attempt is with correct password. I found that there is this bug reported: https://bugs.kde.org/show_bug.cgi?id=481019 but am not sure if that's the same. Anyway, do you guys think that I should open an issue here, agains the locker, or append the above mentioned one, or open an issue against nixos?
If the pam/krb5 module is causing this, then it's certainly not KDE's bug. Depending on what angle you're looking at the issue from, it could be considered an issue with the module, the distro's packaging, or the user's configuration.