https://bugs.kde.org/show_bug.cgi?id=469951
--- Comment #6 from Ta-Lun Yen <e...@evsfy.com> --- (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. -- You are receiving this mail because: You are watching all bug changes.
