Darren/James:
If multithread PAM is the right way to address these problems, then I am
all for working to get the multithread PAM module support code upstream into
GDM. I know this code is already in CDE login.
http://bugzilla.gnome.org/show_bug.cgi?id=464637
However, I'm still a bit uncomfortable with the threadsafe issues. How
are these to be resolved? Should the PAM module have logic to ensure that
it never tries sending multiple messages to GDM at the same time, perhaps
by serializing all messages? Or should the GDM patch be updated so this
serialization is done in the GDM code? Or do we just know that the two PAM
threads would never try to send messages at the same time due to the way
PAM works?
It does seem that the PAM_MSG_NOCONF message type which doesn't expect
confirmation to be used only by thread #2 is a bit hacky. If you guys
tell me that this is really the right solution for solving this problem,
then I will put this code upstream into GDM. You can read more in the
bug report link above, note comment #5.
Also, it would be handy if someone could provide some of the answers to
the questions posed by Ray Strode, just to answer why we at Sun think
this code is a good idea.
Brian
>>> Using this approach, when a user puts their finger on the fingerprint
>>> reader,
>>> a daemon could tell GDM to restart using the fingerprint PAM stack.
>>> This
>>> sort of approach could also work and wouldn't require extending PAM at
>>> all.
>>
>> One of the key questions underlying all of this has been the question
>> of *which* GDM, if there are multiple, should get the event from
>> *which* reader. If you bind together the biometric reader with the
>> existing keyboard/mouse/ display group, then it's easy to see how this
>> works. If the fingerprint reader is dangling in space, it's less
>> obvious how it works.
>
> That problem isn't unique to fingerprint readers, smartcards suffer from
> exactly the same problem. In fact any USB device does - especially when
> used with Sun Ray.
>
