Closed skruppy closed 5 months ago
I think the key part of both possible solutions is adding to a queue instead of blocking. Maybe there can be an option to combine non-prompt requests.
The simplest (but may not be best) solution I can think of is to create a new thread which acquires a mutex lock and sends info messages instead of directly acquiring a mutex lock.
Test setup
In order to authenticate to
su
suing password OR fingerprint I used the following setup. Relevant contents of/etc/pam.d/su
:Content of
/etc/pam.d/any-fingerprint
:Content of
/etc/pam.d/any-password
:Problem description
When trying to authenticate using a fingerprint, the authentication does not succeed until a (invalid/empty) password is provided as shown here:
Cause of the issue
This is caused by
pam_unix
always being faster asking for a password thanpam_fprintd
wanting to print some informational notices. Due to the mutex placed on the upstream conversation, the progress ofpam_fprintd
is halted at the output request of the info message until an user input has been provided topam_unix
. Hence thepam_fprintd
module never returns any result beforepam_unix
.Possible solutions
Reply non-promt requests from queue
For non
promt_*
calls likeinfo()
orerror()
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 likeinfo()
orerror()
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.