| Summary: | Fingerprint auth times out after a certain number of seconds; after this, it can only be re-activated by entering your password incorrectly | ||
|---|---|---|---|
| Product: | [Plasma] plasmashell | Reporter: | Aaron Kelley <dock-agreed-corned> |
| Component: | Screen locking | Assignee: | Plasma Bugs List <plasma-bugs-null> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | adorkablue1996, es, eugene.savitsky, gosu38, kde-bugzilla.oink169, kdedev, kde_org, lee295012, nate, postix, spethmanngabri |
| 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=458130 | ||
| Latest Commit: | Version Fixed/Implemented 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. *** Bug 487635 has been marked as a duplicate of this bug. *** *** Bug 500694 has been marked as a duplicate of this bug. *** *** Bug 481086 has been marked as a duplicate of this bug. *** This is no solution for the bug, but a workaround for everybody who is annoyed of not functioning fingerprint.
For me entering a wrong password did not reset the fingerprint. Claude helped me add a button to the lock-screen that resets the entire greeter. This also restarts fprintd and I can log in with fingerprint again, even if the previous try timed out.
I did not look into security measures and if this button could be exploited to run something else. Please be careful about this!!
Here is a more complete report, but is written by AI and not double checked (Engineer here, no programmer):
################## CAUTION AI ##########################
Workaround: a lock screen button that restarts the greeter
Plasma 6.6.4, Wayland. This is a local workaround, not a fix — the 30 s window is unchanged, it just makes running out of it cost one click instead of the password.
Written by Claude Opus 5
A new greeter process is the only thing that reliably re-arms the fingerprint stack here. ksld lives in kwin_wayland, not in the greeter, so killing the greeter leaves the session locked and untouched while ksld respawns it. Recovery measured at ~3.3 s from press to fingerprint unlock, with the new greeter up 107 ms after the kill.
Three additions to /usr/share/plasma/shells/org.kde.plasma.desktop/contents/lockscreen/LockScreenUi.qml (line numbers as shipped in 6.6.4):
1. After the import block (~line 20):
import org.kde.plasma.plasma5support as Plasma5Support
2. Inside the root Item, after id: lockScreenUi (~line 23):
Plasma5Support.DataSource {
id: fingerprintRetry
engine: "executable"
connectedSources: []
onNewData: (sourceName, data) => disconnectSource(sourceName)
function retry() {
connectSource("/usr/bin/pkill -x kscreenlocker_g");
}
}
3. As the first entry of actionItems: (~line 297), beside Sleep / Hibernate / Switch User:
ActionButton {
text: i18ndc("plasma_shell_org.kde.plasma.desktop", "@action:button", "Retry &Fingerprint")
icon.name: "fingerprint"
onClicked: fingerprintRetry.retry()
},
Two things about that command that cost time to get right:
- kscreenlocker_g is not a typo. The kernel caps a process's comm at 15 characters, so pkill -x kscreenlocker_greet matches nothing and the button silently does nothing. pgrep warns about this; pkill does not.
- pkill -f, as suggested in bug 506658, over-matches — -f tests the full command line, which includes that of the shell running pkill itself.
- The absolute path is deliberate: the button runs unauthenticated from the lock screen and shouldn't user-writable directory.
Notes for anyone trying this: LockScreenUi.qml is a package file, not a conffile, so any plasma-desktoently. You can develop against it safely — copy the shell package elsewhere, point XDG_DATA_DIRS at it,and use kscreenlocker_greet --testing to load the QML in a window without locking anything. And broken regardless: the greeter logs Failed to load lockscreen QML, falling back to built-in locker and thebuilt-in locker still takes the password.
|