Darren:
I would also like to suggest that the project team should specify
what requirements must be followed by programs that support these
features to follow.
For example, the Fingerprint team should specify any assumptions that
GDM must follow for this to work properly. Does GDM need to do
anything special, for example, to manage the new PAM_MSG_NOCONF
message type and how it interacts with other PAM mesages. So, if
GDM needs any special logic for this to work, it should be documented.
I'd like to add such documentation to the GDM docs. If these new
interfaces require special code in the PAM module, then that should
also be specified and perhaps some example multithreaded PAM module
code. So it is clear to people outside of Sun who see these interfaces
how to properly write PAM modules that use these new message types.
The Linux community has already messed up their PAM implementation
a bit, so my thinking is I don't want to encourage more by just
adding new PAM message types to GDM without documentation.
Also, if anybody who really understands PAM wants to recommend ways
to improve the PAM (or overall Security) section of the GDM manual,
I'd love to hear ideas for improving it further:
http://www.gnome.org/projects/gdm/docs/2.18/security.html
I'd suspect all this multithread PAM module docs could go in
this section, perhaps as subsection 3.1.1.
For the record, I'll accept the patch upstream into GDM if this level of
documentation is provided and if people don't get too bothered by the
multithreaded issues raised. Otherwise, I plan to leave it as a patch
we apply to the code in our Solaris builds only.
Brian
> Gaopeng Chen - Sun China wrote:
>> Right, many devices integrates the enrollment/verification function into
>> the firmware. If the device is virtualized in X, PAM module is not able
>> to implement the verification, just like the smartcard. So I would not
>> like to introduce the biometric devices in X level. For this project, in
>> the first stage, the solution is focused on a local system(desktop,
>> laptop). In the second stage, when nis/ldap is supported, I think SunRay
>> would be prioritized rather than X Biometric Device since all USB
>> devices have already bound in client. Thanks.
>
> I agree with this. If we go down the path of mapping things like a
> fingerprint reader into the X input/output space then I want to make
> sure that a project is done to do this properly for Sun Ray (including
> disk and audio) and that we consider how smartcard is dealt with was well.
>
> I think this project should NOT be introducing multi-threaded PAM
> module, or expecting PAM applications to be multi-threaded nor should it
> be trying to do things with the X input model. I believe that this case
> should following the existing architecture that is used for smartcard
> support via PAM and the login applications. That likely means that the
> currently private (and marked obsolete) message types below should be
> formalised and made Committed - assuming the solve the same problem for
> fingerprint readers that they do for smartcard.
>
> #define PAM_MSG_NOCONF 2001 /* No confirmation from user */
> #define PAM_CONV_INTERRUPT 2002 /* Return from conv() */
>
>
>
