Alan Coopersmith wrote: > Gaopeng Chen - Sun China wrote: >>>> 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 X applications would need updating? Just the PAM clients, which I > thought already needed updating in your proposal to support fingerprints.
Strictly speaking, I don't think it is absolutely necessary to update PAM clients to support fingerprint. It should also be possible to make things work reasonably with a non-multithreaded PAM stack, though perhaps a bit less elegant (in some ways). For example, it should be possible to have a separate daemon listen for fingerprint events and trigger the PAM client to restart using a different PAM stack. 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. I discussed this sort solution with the Fingerprint team several months ago, but I think the multithreaded approach was taken instead because it probably seems to work more smoothly without needing to switch the PAM stack, and perhaps also because CDE login already has this kind of code to support some Smart Card setups. Since Sun Ray works on Linux, I don't think Sun Ray depends heavily on multithreaded PAM modules, though. > I don't know if the model for X Input Extension devices (i.e. those other > than core keyboard and mouse) supports reading back something as large as > an image from an input device though - it's usually reporting something > small like coordinates, or an integer value. In fact, due to the X > Protocol limit on event sizes, you'ld probably have to just send the event > to notify there was a fingerprint image available, then wait for the > application to call for the data via some other method (a new X extension > perhaps, or putting it into a pixmap that can be read via convential X > calls like XGetImage). >
