On Thu, 2007-10-25 at 10:06 -0400, Jeremy Katz wrote:
On Thu, 2007-10-25 at 08:55 -0400, Bryan Clark wrote:
Pushing off from Ben's email on new user creation [1] I wanted to get some setup for the think finger support that david mentioned [2].
I'd actually like to make it a teensy bit more general and think about the non-Thinkfinger readers also. From my Pile Of Laptops, the Authentec readers are pretty common. And davidz has already done some prodding with them based on his blog ;)
So the one way to do this sanely is to build a simple API that will work for our purposes; e.g. make it high-level driven by application requirements. Since messing around with auth tokens / whatever is a privileged operation, expose it over D-Bus and lock it down via PolicyKit. It doesn't need to be more complicated than the API offered by tf-tool
# tf-tool --help
ThinkFinger 0.3 (http://thinkfinger.sourceforge.net/) Copyright (C) 2006, 2007 Timo Hoenig thoenig@suse.de
Usage: tf-tool [--acquire | --verify | --add-user <login> | --verify-user <login> ] [--verbose]
Notably, to make fingerprint enrollment work in a sane way (we're so not going to do crazy stuff like running X11 apps as root) _anyway_ you need to expose it over D-Bus. And, really, it's pretty trivial, only a matter of a few hours in C; see
on details how to do it. Hey, you can even do it in Python and since it only involves shelling out to tf-tool, it's probably on the order of hundreds of lines. Now, when we have this API we'll just merge the following properties on the hal device object
info.capabilities += 'fingerprint_reader' fingerprint_reader.dbus_service = 'com.example.ThinkfingerService' fingerprint_reader.dbus_obj = '/' fingerprint_reader.dbus_iface = 'org.freedesktop.FingerPrinterReader'
so if someone wants to do Authentec or whatever they just do a D-Bus and make an object that implements the org.freedesktop.FingerPrinterReader D-Bus interface. Then they merge
info.capabilities += 'fingerprint_reader' fingerprint_reader.dbus_service = 'com.example.AuthentecService' fingerprint_reader.dbus_obj = '/' fingerprint_reader.dbus_iface = 'org.freedesktop.FingerPrinterReader'
Our UI apps simply don't care what fingerprint_reader.dbus_service is; they only care about poking an object with the D-Bus interface org.freedesktop.FingerPrinterReader. So the UI simply does
1. hal.find_by_caps('fingerprint_reader') 2. read .dbus_service, .dbus_obj, .dbus_iface 3. checks that .dbus_iface=='org.freedesktop.FingerPrinterReader' 4. calls into the service 5. profit
David
While not very relevant to the interaction, it's mostly important so that we don't make assumptions of hardware capabilities that may or may not be present.
Can it's presence be detected automatically? And it's (pam) authentication be added automatically?
They're all usb devices, so pretty detectable. Adding the pam config is just a matter of deciding we're doing it and then adding to the stacks written out by authconfig
How many times does it take to train think finger support initially?
This probably depends on the hardware. Thinkfinger is 3 swipes and trained in hardware. Some of the other readers just give you back an image and you have to do verification[1] on your own. But probably 3 is a reasonable guess there too. It's at least the range of "more than one, less than many"
Can it be (re)trained incrementally? Is this required?
Nope, you pretty much have to do the initial readings upfront.
Can we get the image from think finger for user feedback? Ray mentioned we might be able to fake it, which would probably be good enough.
This is definitely going to be dependent on the hardware, so probably can't be counted on.
Can we detect / remember the number of failed think finger attempts before a successful one? This is related to retraining, if it's possible to retrain the reader or human to scan better over time.
PAM doesn't usually keep track of a number of failures. You could have a module do it, though if you really wanted I think.
Jeremy