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