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@xxxxxxx> > > 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 http://blog.fubar.dk/?p=94 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 > -- Fedora-desktop-list mailing list Fedora-desktop-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-desktop-list
