Hi Alan, The question is about the virtualization of biometric devices in X level, just the other input devices(keyboard, mouse). James suggests that the biometric devices should be virtualized and accessed by the X application instead of the PAM module. The PAM module gets the biometric input from the separate X instance via the conversation function. Then each X instance may be bound to the set of "keyboard+mouse+screen+biometric". I explained that this would not be suitable for this project in the former mail.
((( > > architecture design. Many biometric devices integrate the verification > > function in the firmware. If biometric device is virtualized in X, > > pam_bio can't access the device, how can we implement the verification? > > let gdm call bio_verify() directly? It's too weired. Similar to > > What do we do with keyboards and displays today? The PAM function > talks to the verifier, and the framework itself handles the I/O to the > user. > > That same model seems to apply here. For the biometric devices that just capture images(just as keyboards get username/password), the PAM module gets the image and verify it by comparing with data records. They have the same model. However, for the biometric devices that integrate the verification module in the firmware, the devices directly return the verification/identification result(the data records are preloaded into the firmware). If the biometric devices are virtualized in X and only accessed by the application, how does the PAM module implement the authentication? So I'd like to keep the biometric devices accessed by PAM modules, just like smartcard and javacard cases. ))) And it would need a lot of resources to update all the X applications. What do you think of it? Thanks. On Fri, 2007-08-17 at 14:45, Alan Coopersmith wrote: > Gaopeng Chen - Sun China wrote: > >>> 2) Is it necessary to import virtual Biometric Device in X level(or even > >>> in console level)? [No] > >>> > >>> It's too ideal to regards biometric devices as the keyboard/mouse. If > >>> biometric devices is virtualized, we not only update the X > >>> applications(such as gdm, dtlogin, etc), but also updates the console > >>> applications(such as login, su, etc). I didn't ask for X team, but I > >>> don't think we have so many resources to update all PAM authentication > >>> services. Further more, a problem may be difficult to be resolved for > >> I suggest asking. You may be right, and the answer may be "never" as > >> you indicate, but I don't think that guessing at another team's > >> resources or priorities is a good way to proceed. > > I've mailed Alan.Coopersmith for this, just please wait for the > > response. > > I'm not sure I actually understand what here you want me to respond to. > The X team only owns three of the PAM clients - xlock, xdm, and > xscreensaver - of which xscreensaver is the only interesting one to > most people. We have no plans to make any of the three multithreaded > or support PAM_CONV_INTERRUPT though. xscreensaver's PAM code is far > too complex and brittle already for me to want to even think about > multi-threading it. > > If there's a more involved question hiding in here you want me to > answer, can you please state it simply? > > > -- > -Alan Coopersmith- alan.coopersmith at sun.com > Sun Microsystems, Inc. - X Window System Engineering -- Best Regards, GaoPeng Chen Call: +86-10-62673005 Ext: x82005 Sun Microsystem Inc. China
