I recently moved from Plasma 5.24.7 to Plasma 5.27.5 and have observed a change in behavior in how fingerprint unlock from the lock screen works. For me, this has made the experience of getting past the lock screen more annoying. Note that here I am referring to getting past the lock screen (kscreenlocker), not the initial login screen (sddm). Plasma 5.24 behavior: I am presented with a password prompt and not prompted to do a fingerprint scan until I hit "enter". Entering a blank password is fine, it will then prompt me to scan my finger and log me in after a successful scan. Plasma 5.27 behavior: The system immediately prompts for a fingerprint scan if I press any key or move the mouse. I don't have to hit "enter" at the password prompt to get it to ask for a scan. This *seems* like an improvement since I can get into the system more quickly. The problem comes from the fact that it is easy to disturb the lock screen and have it prompt for a scan when I'm not actually ready to log in yet. I'm just using a laptop with a USB mouse attached, and if I have the screen locked and pick the system up to move it to a different location, kscreenlocker will think that I'm ready to do a fingerprint scan. A few minutes later when I'm actually ready to do a scan, it has already errored out. So, we have some issues. STEPS TO REPRODUCE 1. Set PAM fingerprint timeout to 30 seconds. (/etc/pam/common-auth) 2. Lock the KDE Plasma session. 3. Move the mouse. kscreenlocker system prompts for a fingerprint scan. 4. Wait 30 seconds. OBSERVED RESULT The scan times out and results in the error message "Verification failed". The proceed, I have to hit enter at the empty password box, watch the shake/failure animation, and then wait a few seconds before it will allow me to try again. So in the end, it takes *longer* than it took with Plasma 5.24. EXPECTED RESULT ...I wasn't even ready to scan yet. Wait until I take explicit action before starting a scan, or, automatically retry the scan after failure. ===== I tried increasing the fingerprint scan timeout to get around this issue. If kscreenlocker would just sit and wait patiently until I am really ready to do a fingerprint scan, then there would be no problem. It turns out that there's a bug in libpam-fprintd that prevents setting the timeout higher than 99 seconds, but I got around that by applying this unmerged patch. See: - https://gitlab.freedesktop.org/libfprint/fprintd/-/issues/147 - https://gitlab.freedesktop.org/libfprint/fprintd/-/merge_requests/195 Regardless, increasing the timeout does not help me solve this problem. STEPS TO REPRODUCE 1. Set PAM fingerprint timeout to 99 seconds. (/etc/pam/common-auth) 2. Lock the KDE Plasma session. 3. Move the mouse once. kscreenlocker prompts for a fingerprint scan. 4. Wait 99 seconds. OBSERVED RESULT kscreenlocker appears to give up on PAM fingerprint authentication approximately 88 seconds after issuing the fingerprint scan prompt. I got this from tracing through entries in auth.log with libpam-fprintd "debug" mode turned on, and observing the steps that it is going through in the libpam-fprintd code. In libpam-fprintd, the poll is interrupted early and it gets back an error "verify-unknown-error". (This is not the case with, for example, a sudo password prompt; it will wait as long as I have configured for a fingerprint scan.) At this point, fingerprint authentication is broken. Despite kscreenlocker issuing another request for me to scan my finger, the only way forward is to enter my password. EXPECTED RESULT kscreenlocker should wait indefinitely for a fingerprint scan. The timeout is configured by PAM. ===== Alternatively, is there a way to configure kscreenlocker to just not try to do a fingerprint scan until I hit "enter" at the password prompt, like it did in Plasma 5.24? SOFTWARE/OS VERSIONS Linux/KDE Plasma: Kubuntu 23.04, Linux kernel 6.2 KDE Plasma Version: Plasma 5.27.5 KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8
> kscreenlocker should wait indefinitely for a fingerprint scan. The timeout is configured by PAM. I agree that waiting forever would be ideal but then wouldn't we need the timeout adjusted in the system's PAM configuration?
I would suggest that kscreenlocker should just go with whatever timeout PAM is configured to use. Since PAM is used in more places than just kscreenlocker, it isn't really KDE/Plasma's job to "set" the value there, just let the user do it if they so choose. If a user hits an issue like mine where the fingerprint reader timeout is an issue, raising the timeout would effectively solve it. As it stands, (at least for me) setting a long timeout doesn't seem to fix the problem. kscreenlocker does not wait for it to expire before giving up on PAM fingerprint authentication. This is illustrated by my test case described earlier; set the timeout to 99 seconds (...or higher, but that currently requires patching fprintd...) and kscreenlocker will end the PAM authentication session after ≈90 seconds. I haven't had a chance to dig into the kscreenlocker code yet to see exactly what is going on here. I've only looked at the libpam-fprintd side of things so far.
(As a note for anyone who may look into this. libpam-fprintd documentation suggests that setting "-1" for an "unlimited" timeout is allowed, but that is *also broken* in the current release. If you set it to -1, you will get the default 30 second timeout window. I'm soon going to be rattling around on their end to get that fixed. There is already a PR that solves it but it has been sitting for five months without any merge or activity.)
Not having any timeout might also be bad, for example if you switch to TTY, and for some reasons you cant touch fingerprint sensor or its broken, you might end up stuck not being able to type password to login, because now it waits for the fingerprint sensor to timeout/fail before asking for password. Same happen in the lockscreen, if you have fingerprint enabled, I move the mouse, type password, hit enter, and .... i still need to wait for it to timeout before it checks the provided password and get me logged in.