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() */ -- Darren J Moffat
