pam: add optional fingerprint authentication

[rjarry]

Allow unlocking the screen with a fingerprint reader via pam_fprintd. When enabled with -p/--fingerprint, a child process is spawned that runs in parallel with normal password authentication. Users can unlock with either method, whichever succeeds first.

The fingerprint child blocks on pam_authenticate() using a dedicated swaylock-fingerprint PAM service. On success, it notifies the parent via a pipe. On failure, it retries until a valid fingerprint is detected. The child terminates automatically when the parent exits.

This achieves the same feature than #283 but without any additional dependencies.

[hboetes]

Nice PR. I accidentally happen to maintain a fork of a fork of fork of a fork of this project, which also has a fingerprint scanner, including support for fingerprint scanners which shut down after some time. Perhaps you'd like to take a peek?

https://github.com/hboetes/swaylock-effects

[rjarry]

Hi @hboetes, thanks for the link. I will have a look.

I wonder, why not contribute your security fixes and quality of life improvements to the original project?

I guess some eye candy things aren't essential and would go against the minimalist nature of sway{,lock}. But security issues should be reported and fixed.

[emersion]

Is there no way to run pam_fprintd in such a way that it runs normal login authentication alongside fprintd?

[rjarry]

Unfortunately, no. In order to talk to fprintd, you need to start a PAM challenge. In order to avoid any DBUS dependency, I resorted to a separate blocking PAM conversation with only pam_fprintd.so and that sends an "empty" password.

[hboetes]

Hi @hboetes, thanks for the link. I will have a look.

I wonder, why not contribute your security fixes and quality of life improvements to the original project?

I guess some eye candy things aren't essential and would go against the minimalist nature of sway{,lock}. But security issues should be reported and fixed.

Because I have been using swaylock-effects for ages. I was wondering if the fingerprint scanner code might be useful for the original project, searched around and found your PR, didn't want to rain on your parade, but rather add to it, assuming you might find useful bits in it.

I am not aware where the security problems @ink-splatters and I found and came from, just that they existed in the swaylock-effects code.

[rjarry]

I was wondering if the fingerprint scanner code might be useful for the original project, searched around and found your PR, didn't want to rain on your parade, but rather add to it, assuming you might find useful bits in it.

Thanks for shining in 👍

I had a quick look at your implementation. It is quite well integrated with actual GUI feedback but unfortunately requires additional libdbus and glib dependencies which swaylock does not have at the moment.

I remember @emersion saying that he preferred to keep the dependencies as lean as possible in #283 which led me to add this PR.

[emersion]

Unfortunately, no. In order to talk to fprintd, you need to start a PAM challenge. In order to avoid any DBUS dependency, I resorted to a separate blocking PAM conversation with only pam_fprintd.so and that sends an "empty" password.

What I mean is that a PAM backend can do all of this dance?

[rjarry]

Hey Simon,

I had looked into this and unfortunately a single PAM service with both pam_fprintd.so and pam_unix.so does not work because auth modules run sequentially. Whichever module comes first in the stack blocks waiting for its input (fingerprint scan or password typing), preventing the next one from running until it either succeeds, times out or fails.

To have both methods available simultaneously, you would need to talk to fprintd directly over D-Bus to start and cancel verify operations, which would add libdbus/libglib dependencies. The separate child process with its own PAM conversation avoids that while still allowing both methods to race in parallel.

Let me know if you have another idea I might have missed.