think finger

[David Zeuthen]

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 at 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

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
>