Bug 469951 - With fingerprint login, odd behaviors if you do not perform a scan promptly
Summary: With fingerprint login, odd behaviors if you do not perform a scan promptly
Status: CONFIRMED
Alias: None
Product: kscreenlocker
Classification: Plasma
Component: general (show other bugs)
Version: 5.27.5
Platform: Kubuntu Linux
: NOR minor
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords: usability
Depends on:
Blocks:
 
Reported: 2023-05-18 14:59 UTC by Aaron Kelley
Modified: 2023-08-03 12:54 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Kelley 2023-05-18 14:59:17 UTC
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
Comment 1 Nate Graham 2023-05-19 19:41:57 UTC
> 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?
Comment 2 Aaron Kelley 2023-05-19 19:55:29 UTC
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.
Comment 3 Aaron Kelley 2023-05-19 19:59:24 UTC
(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.)