| Summary: | With fingerprint login, odd behaviors if you do not perform a scan promptly | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Aaron Kelley <dock-agreed-corned> |
| Component: | Screen locking | Assignee: | Plasma Bugs List <plasma-bugs> |
| Status: | CONFIRMED --- | ||
| Severity: | minor | CC: | adorkablue1996, es, kdedev, kde_org, lee295012, nate, postix |
| Priority: | NOR | Keywords: | usability |
| Version First Reported In: | 5.27.5 | ||
| Target Milestone: | 1.0 | ||
| Platform: | Kubuntu | ||
| OS: | Linux | ||
| See Also: |
https://bugs.kde.org/show_bug.cgi?id=500694 https://bugs.kde.org/show_bug.cgi?id=458130 |
||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
Aaron Kelley
2023-05-18 14:59:17 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?
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. I can also confirm this on 6.3.3. I can also confirm that this behavior exists. I'd recommend against having an infinite timeout, but rather, fail the entire login attempt upon timeout from non-interactive modules (fingerprint and smartcard). In case of pam_u2f, although not officially supported in kscreenlocker, does not allow setting an infinite timeout (https://github.com/Yubico/pam-u2f/issues/25). PAM modules also doesn't supports concurrency, so if a fprintd session is held by kscreenlocker, the entire system will be unable to use it. Speaking of timeouts: In case of pam_fprintd, it emits PAM_AUTHINFO_UNAVAIL on timeout, so we can discern between a timeout and a genuine failure. For pam_pkcs11 it defaults to not expire and its upstream does not imply an event type upon timeout. For fprint, having a broken fingerprint reader or having no reader at all, or to have fingerprint auth enabled but without a finger enrolled will also emit PAM_AUTHINFO_UNAVAIL. Therefore, I propose we implement PAM_AUTHINFO_UNAVAIL as a "timeout or unavailable" signal. Further on, in case of PAM_AUTHINFO_UNAVAIL with non-interactive modules, should we close the login prompt (if possible), so it won't try failing itself again over time when the user is not yet ready? (In reply to Ta-Lun Yen from comment #5) > I can also confirm this on 6.3.3. I can also confirm that this behavior > exists. I'd recommend against having an infinite timeout, but rather, fail > the entire login attempt upon timeout from non-interactive modules > (fingerprint and smartcard). In case of pam_u2f, although not officially > supported in kscreenlocker, does not allow setting an infinite timeout > (https://github.com/Yubico/pam-u2f/issues/25). PAM modules also doesn't > supports concurrency, so if a fprintd session is held by kscreenlocker, the > entire system will be unable to use it. > > Speaking of timeouts: In case of pam_fprintd, it emits PAM_AUTHINFO_UNAVAIL > on timeout, so we can discern between a timeout and a genuine failure. For > pam_pkcs11 it defaults to not expire and its upstream does not imply an > event type upon timeout. For fprint, having a broken fingerprint reader or > having no reader at all, or to have fingerprint auth enabled but without a > finger enrolled will also emit PAM_AUTHINFO_UNAVAIL. Therefore, I propose we > implement PAM_AUTHINFO_UNAVAIL as a "timeout or unavailable" signal. > > Further on, in case of PAM_AUTHINFO_UNAVAIL with non-interactive modules, > should we close the login prompt (if possible), so it won't try failing > itself again over time when the user is not yet ready? Taking another look and it appears I had mistaken: the default behavior on 6.3.3 is to allow fingerprint OR password auth (/etc/pam.d/kde and /etc/pam.d/kde-fingerprint in parallel). If a fingerprint reader times out, it's still possible to login using password. |