Both xlock (from xlockmore) and i3lock will prompt for password, followed by requiring me to touch the fingerprint sensor (but with no UI feedback), before actually unlocking the screen. If I only enter the password, but did not touch the fingerprint sensor, the lock screen will sit there waiting for me to do it (again, with no UI feedback that it is waiting for me to do so).
This behaviour is strange, and is only happening with fprintd enabled. For the record, this is what I have in my config:
I have the same problem with gdm. I think I have tracked this down. The pam module generates the /etc/pam.d/screensaver file which includes the two lines if fingerprint auth is enabled:
You are correct, the Arch WIki also suggests that order. I’m going to try and submit a PR to add an option to invert the order of the fingerprint vs password auth.
Hey, as far as I know I never had a different behavior and that is somehow a limitation of using pam (as it can’t handle concurrent verification if I rephrase it correct?) lastly that’s why i lastly switched to GitHub - SL-RU/swaylock-fprintd: Screen locker for Wayland with fingerprint support via fprintd it implements the fingerprint-unlock concurrent to password-unlock via dbus instead of pam but you would need to use sway/wayland or port it to i3lock if you don’t want to…
as it can’t handle concurrent verification if I rephrase it correct?
Correct. To quote pam_fprintd(8):
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.