SUMMARY Once I've configured Fingerprint Authentication, I can't unlock the screen with the password anymore. It's useful for multiple reasons: sometimes it's closed and attached to external peripherals sometimes someone else need to log in and I could tell them the password STEPS TO REPRODUCE 1. Open System Settings > User > Configure Fingerprint Authentication 2. Lock the screen 3. Try to unlock with password OBSERVED RESULT It asks for the fingerprint, and fail with the password even if correct. EXPECTED RESULT It unlock the screen. SOFTWARE/OS VERSIONS Operating System: Fedora Linux 36 KDE Plasma Version: 5.24.5 KDE Frameworks Version: 5.93.0 Qt Version: 5.15.3 Kernel Version: 5.17.6-300.fc36.x86_64 (64-bit) Graphics Platform: Wayland
Can reproduce. Not sure if this is something we can fix on our side, or if it's a PAM configuration thing. FWIW you'll be able to use your text password if you try and fail to authenticate with a fingerprint three times.
I have the same issue on a fedora 38 beta. After failing three times the fingerprint, I can indeed type my password to unlock It works the other way around: I can type my password, hit enter (nothing happens), and then fail three times the fingerprint; the computer unlocks. The problem might not be on kde side, as it is also present with other programs. For instance, if I use sudo, I need to fail three times the fingerprint before being offered a keyboard prompt.
Yeah I'm pretty sure this is a PAM issue unfortunately.
I agree it should be PAM's job, but they don't seem to think so. From the manpage for pam_fprintd: The PAM stack is by design a serialised authentication, so it is not possible for pam_fprintd to allow authentication through passwords and fingerprints at the same time. It is up to the application using the PAM services to implement separate PAM processes and run separate authentication stacks separately. This is the way multiple authentication methods are made available to users of gdm for example. So maybe it is up to kscreenlocker to do the work, after all. There must be some code in gdm that could be adapted in kscreenlocker and in sddm.
Ah ok, so there is something we can do about it, cool.