Test setup

In order to authenticate to su suing password OR fingerprint I used the following setup. Relevant contents of /etc/pam.d/su:

[...]
auth            required        pam_any.so {"any-fingerprint": "Fingerprint", "any-password": "Password"}
[...]

Content of /etc/pam.d/any-fingerprint:

auth            required        pam_fprintd.so
account         required        pam_permit.so

Content of /etc/pam.d/any-password:

auth            required        pam_unix.so
account         required        pam_permit.so

Problem description

When trying to authenticate using a fingerprint, the authentication does not succeed until a (invalid/empty) password is provided as shown here:

$ pamtester su skruppy authenticate
[Password] Password: 
[Fingerprint] Place your right index finger on the fingerprint reader
pamtester: successfully authenticated

Cause of the issue

This is caused by pam_unix always being faster asking for a password than pam_fprintd wanting to print some informational notices. Due to the mutex placed on the upstream conversation, the progress of pam_fprintd is halted at the output request of the info message until an user input has been provided to pam_unix. Hence the pam_fprintd module never returns any result before pam_unix.

Possible solutions

Reply non-promt requests from queue

For non promt_* calls like info() or error() add them to a queue during an ongoing promt-call and reply them once the promt is done.

Combine non-promt requests

For non promt_* calls like info() or error() collect the messages in a single concatenated message during an ongoing promt-call. Send this concatenated message once the promt-call has finished.

This has the advantage that GUIs which might only show a single message at a time do not only show the last queued message, but all of them.

Thank you for developing this module.

I think the possibility to decide whether all or just one the modules called by pam_any have to succeed would be pretty nice.

Example 1: I use both howdy and a bluetooth module and only want PAM to accept me if my face gets recognized AND my smartphone is reachable via BT.

Example 2: If I used howdy and a fingerpint reader, I would probably want to only do one of both at a time, so I would need an OR check. (This is already implemented)

According to pam(3)

The libpam interfaces are only thread-safe if each thread within the multithreaded application uses its own PAM handle.

Looks to me like the current implementation either is unsound due to violating libpam thread-safety requirements or relies on some internal libpam implementation details for soundness.