SUMMARY After successfully unlocking screen with fingerprint, password PAM session fails. If pam_faillock is enabled, it leads to account locking after few fingerprints unlocks in short time. STEPS TO REPRODUCE 1. Lock screen 2. Unlock with fingerprint OBSERVED RESULT > pam_unix(kde:auth): authentication failure; logname=... After 3 unlocks: > pam_faillock(kde:auth): Consecutive login failures for user ... account temporarily locked EXPECTED RESULT No failures SOFTWARE/OS VERSIONS KDE Plasma Version: 6.0.1 KDE Frameworks Version: 6.0.0 Qt Version: 6.6.2 Graphics Platform: Wayland
Hello all, After installing and configuring the fingerprint sensor, I had the same issue as above. But I think I have found a workaround. Please note however that I am far from an expert and I maybe wrong. I am on EndeavourOS using KDE Plasma 6.0.2, linux 6.6.22-1-lts on a thinkpad X270. Based on man pam_fprintd: ``` LIMITATIONS The PAM stack is by design a serialised authentication, so it is not possible for pam_fprintd to allow authentication through passwords and fingerprints at the same time. It is up to the application using the PAM services to implement separate PAM processes and run separate authentication stacks separately. This is the way multiple authentication methods are made available to users of gdm for example. ``` Since kscreenlocker does permit both password and finderprint at the same time, I believe this is what it does. That is, it uses two separate PAM processes: One, let's call it password PAM process, is using the /etc/pam.d/kde configuration. The other, let's call it fingerprint PAM process, using the /etc/pam.d/kde-fingerprint configuration. kscreenlocker will unlock if any of the two above PAM processes succeeds. The other however will fail. When using the password PAM process, succesful login will clear the previous faillock incidents. This is what it happens by observing the contents of the original /etc/pam.d/kde. The fingerprint PAM process though, differs. Unfortunately I didn't keep the original /etc/pam.d/kde-fingerprint, but the updated seems to work correctly: [root@gordon pam.d]# cat kde-fingerprint #%PAM-1.0 auth required pam_shells.so auth requisite pam_nologin.so auth requisite pam_faillock.so preauth # <--- I think I added this line -auth required pam_fprintd.so auth optional pam_permit.so auth required pam_env.so auth required pam_faillock.so authsucc # <--- I think I added this line account requisite pam_faillock.so preauth # <--- Surely added this line account include system-local-login account required pam_faillock.so authsucc # <--- Surely added this line password required pam_deny.so session include system-local-login [root@gordon pam.d]# The above change was based on the following note from pam_faillock: [...] Due to complications in the way the PAM stack can be configured it is also possible to call pam_faillock as an account module. In such configuration the module must be also called in the preauth stage.[...] Using the above configuration and unlocking multiple times using the fingerprint works ok. Still though, there is a single faillock incident after each try, but they do not accumulate. Faillock is being reset by the fingerprint PAM process and just after reset the password PAM process registers a failed incident.
Thank you for the bug report. Unfortunately we were not able to get to it yet. Can we ask you to please check if this is still an issue with Plasma 6.3.2 (the latest released version)? Thanks!
(In reply to TraceyC from comment #2) > Thank you for the bug report. Unfortunately we were not able to get to it > yet. Can we ask you to please check if this is still an issue with Plasma > 6.3.2 (the latest released version)? Thanks! Hello, thank you for your time. I am on Plasma 6.3.0 and it seems resolved but I am on different hardware (same system disk as before but on a different laptop). It works ok and it doesn't lock me out as before after a few succesful but in short time logins. I do however get a relevant message on the logs everytime I succesfully login with fingerprint: Μαρ 05 07:17:07 gordon kscreenlocker_greet[1299820]: pam_unix(kde:auth): username [haritak] obtained Μαρ 05 07:17:09 gordon kscreenlocker_greet[1299820]: qt.qpa.wayland: Could not create EGL surface (EGL error 0x3000) Μαρ 05 07:17:09 gordon kscreenlocker_greet[1299820]: pam_unix(kde:auth): authentication failure; logname=haritak uid=1000 euid=1000 tty= ruser= rhost= user=haritak Μαρ 05 07:17:09 gordon kscreenlocker_greet[1299820]: Failed to write to the pipe: Εσφαλμένος περιγραφέας αρχείου.
(In reply to TraceyC from comment #2) > Thank you for the bug report. Unfortunately we were not able to get to it > yet. Can we ask you to please check if this is still an issue with Plasma > 6.3.2 (the latest released version)? Thanks! Still locks after 3 successful unlocks with fingerprint on Plasma 6.3.2.
(In reply to Charitakis Yannis from comment #3) > (In reply to TraceyC from comment #2) > > Thank you for the bug report. Unfortunately we were not able to get to it > > yet. Can we ask you to please check if this is still an issue with Plasma > > 6.3.2 (the latest released version)? Thanks! > > Hello, thank you for your time. > I am on Plasma 6.3.0 and it seems resolved but I am on different hardware > (same system disk as before but on a different laptop). > It works ok and it doesn't lock me out as before after a few succesful but > in short time logins. > > I do however get a relevant message on the logs everytime I succesfully > login with fingerprint: > > Μαρ 05 07:17:07 gordon kscreenlocker_greet[1299820]: pam_unix(kde:auth): > username [haritak] obtained > Μαρ 05 07:17:09 gordon kscreenlocker_greet[1299820]: qt.qpa.wayland: Could > not create EGL surface (EGL error 0x3000) > Μαρ 05 07:17:09 gordon kscreenlocker_greet[1299820]: pam_unix(kde:auth): > authentication failure; logname=haritak uid=1000 euid=1000 tty= ruser= > rhost= user=haritak > Μαρ 05 07:17:09 gordon kscreenlocker_greet[1299820]: Failed to write to the > pipe: Εσφαλμένος περιγραφέας αρχείου. One more note which maybe relevant, back then I was using validity-sensors (https://aur.archlinux.org/packages/python-validity) since my hardware was not supported. When I changed my laptop, I had removed validity-sensors and installed fprintd.
Thanks for the updates. I'll let a contributor more knowledgeable about this take it from here.
I'm also running into this bug in Plasma 6.3.2 on Arch Linux. If I turn my computer off and on four times and use fingerprint login, then it locks me out for 10 minutes the fourth time. Adding the line `auth required pam_faillock.so authsucc` to the end of the `auth` section in `/etc/pam.d/kde-fingerprint` fixes this problem for me.
(In reply to Anthony Wang from comment #7) > I'm also running into this bug in Plasma 6.3.2 on Arch Linux. If I turn my > computer off and on four times and use fingerprint login, then it locks me > out for 10 minutes the fourth time. Adding the line `auth required > pam_faillock.so authsucc` to the end of the `auth` section in > `/etc/pam.d/kde-fingerprint` fixes this problem for me. I already had this line in my config, maybe that's why I wasn't locked out. ``` #%PAM-1.0 auth required pam_shells.so auth requisite pam_nologin.so auth requisite pam_faillock.so preauth -auth required pam_fprintd.so auth optional pam_permit.so auth required pam_env.so auth required pam_faillock.so authsucc <-------- this line account requisite pam_faillock.so preauth account include system-local-login account required pam_faillock.so authsucc password required pam_deny.so session include system-local-login ``` If it's not there by default, I can't recall when did I place it there.... sorry.
(In reply to Charitakis Yannis from comment #8) > If it's not there by default, I can't recall when did I place it there.... > sorry. I tracked down where the default `/etc/pam.d/kde-fingerprint` file is coming from and turns out it's not in the KScreenLocker source code but actually shipped by downstream distros, for instance https://gitlab.archlinux.org/archlinux/packaging/packages/kscreenlocker/-/blob/main/kde-fingerprint.pam?ref_type=heads for Arch Linux. So I think this is actually an Arch bug and should be reported there.