[Thinkfinger-devel] [PATCH] tf-tool should be installed in /usr/bin instead

[Luca Capello]

Hello!

After Christian Neumair patchset was included upstream [1], tf-tool
should have been moved to /usr/bin, for two reasons:

1) according to the FHS-2.3 [2]

/usr/sbin : Non-essential standard system binaries

This directory contains any non-essential binaries used exclusively
by the system administrator. System administration programs that
are required for system repair, system recovery, mounting /usr, or
other essential functions must be placed in /sbin instead.

Indeed, now that every single user can have a fingerprint stored in
her/his $HOME, tf-tool (AFAIK the only tool to acquire fingerprints
for ThinkFinger) is no more "used exclusively by the system
administrator".

2) a non-root user $PATH by default doesn't include /usr/sbin, which
means that more documentation should be added to inform the user that
tf-tool is in /usr/sbin and it should be called with the full path.

The following patch install tf-tool into /usr/bin instead:

--8<---------------cut here---------------start------------->8---
diff -Naur thinkfinger.ORG/configure.in thinkfinger/configure.in
--- thinkfinger.ORG/configure.in 2008-03-03 23:57:27.000000000 +0100
+++ thinkfinger/configure.in 2008-03-03 23:54:37.000000000 +0100
@@ -111,7 +111,7 @@
fi
exec_prefix=$EXEC_PREFIX

-# AC_SUBST PREFIX, LIBDIR, BINDIR, SBINDIR, MANDIR, SECUREDIR and BIRDIR
+# AC_SUBST PREFIX, LIBDIR, BINDIR, MANDIR, SECUREDIR and BIRDIR
PREFIX_TMP="$prefix"
PREFIX=`eval echo $PREFIX_TMP`
AC_SUBST(PREFIX)
@@ -124,10 +124,6 @@
BINDIR=`eval echo $BINDIR_TMP`
AC_SUBST(BINDIR)

-SBINDIR_TMP="$sbindir"
-SBINDIR=`eval echo $SBINDIR_TMP`
-AC_SUBST(SBINDIR)
-
if ! test -z "$with_securedir" ; then
SECUREDIR_TMP="$with_securedir"
else
@@ -203,7 +199,6 @@
+ prefix: ${PREFIX}
+ libdir: ${LIBDIR}
+ bindir: ${BINDIR}
- + sbindir: ${SBINDIR}
+ mandir: ${MANDIR}

+ cflags: ${CFLAGS}
diff -Naur thinkfinger.ORG/tf-tool/Makefile.am thinkfinger/tf-tool/Makefile.am
--- thinkfinger.ORG/tf-tool/Makefile.am 2008-03-03 23:57:27.000000000 +0100
+++ thinkfinger/tf-tool/Makefile.am 2008-03-03 23:54:37.000000000 +0100
@@ -1,4 +1,4 @@
-sbin_PROGRAMS = tf-tool
+bin_PROGRAMS = tf-tool

INCLUDES = -I$(top_srcdir)/libthinkfinger

--8<---------------cut here---------------end--------------->8---

FWIW, this patch should be applied after the tf-tool_completion patch
for `make dist*` [3]. And FYI it will be included in the next Debian
package if no one replies against it in the next two days.

Thx, bye,
Gismo / Luca

Footnotes:
[1] http://thread.gmane.org/gmane.linux.drivers.thinkfinger/424/focus=491
[2] http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSBINNONESSENTIALSTANDARDSYSTEMBI
[3] http://thread.gmane.org/gmane.linux.drivers.thinkfinger/525

[Luca Capello]

Hello!
A new patch because of the README.in one at [1], which contains a
reference to /usr/sbin/tf-tool that should be corrected as well.

This is the patch I included in the Debian package.

Thx, bye,
Gismo / Luca

Footnotes:
[1] http://thread.gmane.org/gmane.linux.drivers.thinkfinger/424/focus=538

--8<---------------cut here---------------start------------->8---
--- thinkfinger.orig/configure.in
+++ thinkfinger/configure.in
@@ -111,7 +111,7 @@
fi
exec_prefix=$EXEC_PREFIX

-# AC_SUBST PREFIX, LIBDIR, BINDIR, SBINDIR, MANDIR, SECUREDIR and BIRDIR
+# AC_SUBST PREFIX, LIBDIR, BINDIR, MANDIR, SECUREDIR and BIRDIR
PREFIX_TMP="$prefix"
PREFIX=`eval echo $PREFIX_TMP`
AC_SUBST(PREFIX)
@@ -124,10 +124,6 @@
BINDIR=`eval echo $BINDIR_TMP`
AC_SUBST(BINDIR)

-SBINDIR_TMP="$sbindir"
-SBINDIR=`eval echo $SBINDIR_TMP`
-AC_SUBST(SBINDIR)
-
if ! test -z "$with_securedir" ; then
SECUREDIR_TMP="$with_securedir"
else
@@ -203,7 +199,6 @@
+ prefix: ${PREFIX}
+ libdir: ${LIBDIR}
+ bindir: ${BINDIR}
- + sbindir: ${SBINDIR}
+ mandir: ${MANDIR}

+ cflags: ${CFLAGS}
--- thinkfinger.orig/tf-tool/Makefile.am
+++ thinkfinger/tf-tool/Makefile.am
@@ -1,4 +1,4 @@
-sbin_PROGRAMS = tf-tool
+bin_PROGRAMS = tf-tool

INCLUDES = -I$(top_srcdir)/libthinkfinger

--- thinkfinger.orig/README.in
+++ thinkfinger/README.in
@@ -158,7 +158,7 @@

[2] Example how to store a fingerprint image for user 'bob'

-***@host~> /usr/sbin/tf-tool --acquire
+***@host~> tf-tool --acquire

( Now user 'bob' has to swipe his finger three times )

--8<---------------cut here---------------end--------------->8---

[Daniel Hauck]

First I'd like to say that I'm "just a user" and not a developer. Next
I'd like to say that Thinkfinger as I am using it at the moment
(thinkfinger-0.3-7.fc8) works pretty darned well!

It works very well for a single-person identification method. But what
if I wanted to set up an authentication system for a small data center
and wanted to have several users capable of authentication as root?

But rather than ask questions like this, I think it would be appropriate
if there were some sort of scope and developmental road map that I could
reference before making stupid suggestions that have either already been
considered and thrown out or have already been planned.

In any case, let this message serve primarily as a thank you for having
created this support. It's pretty awesome. I'm puzzled by how there
was no "driver" created for the device. I think it's the first time I
have seen a device being used under Linux without a device driver having
been created to access it. I don't know whether to think this is really
cool or very against the rules. Either way, it works very well and
makes it easier to increase security without making things too inconvenient.

[Daniel Drake]

Post by Daniel Hauck
It works very well for a single-person identification method. But what
if I wanted to set up an authentication system for a small data center
and wanted to have several users capable of authentication as root?

thinkfinger supports verification which is a one-to-one comparison of a
fresh scan against a previously enrolled print.
For your data center you need identification instead, a comparison of a
fresh scan to a collection ("gallery") of previously enrolled prints.

The protocol for these devices has been reverse engineered through bus
traffic analysis, and it has only been reverse engineered to the point
where we can do verification.

These devices work differently from the majority of other fingerprint
readers. Most fingerprint readers just provide an image of the finger to
the computer and let the software decide whether a login should be
authorized. In this case, the device does image processing *in hardware*
and the protocol we use simply gives us a "yes" or "no" answer for
verification - it doesn't present us with images. This means that we're
constrained to the limits of the protocol (and/or our limited knowledge
of it).

I have been told recently that UPEKs own binary linux software does
support identification, in that you can use a fingerprint to select the
username *and* password (so it must be doing a one-to-many comparison
between fresh print and all enrolled users). So identification should be
possible, but it's a long way down on my list.

Also, under windows these devices do present images to the computer, so
it looks like there is an alternative protocol we could use. However
that protocol is entirely unknown. I briefly looked at bus traffic under
windows and decided that the protocol being used there is
encrypted/scrambled, making it quite unrealistic for us to be able to
reverse engineer it.

Post by Daniel Hauck
In any case, let this message serve primarily as a thank you for having
created this support. It's pretty awesome. I'm puzzled by how there
was no "driver" created for the device. I think it's the first time I
have seen a device being used under Linux without a device driver having
been created to access it. I don't know whether to think this is really
cool or very against the rules.

thinkfinger uses libusb to talk to the device. libusb is a library which
allows you to write USB drivers in userspace. It's built on top of the
USB device filesystem (usbfs) kernel feature.

It's not against the rules by any means :)
libusb is used by many other projects including SANE (for scanners) and
(soon) CUPS (for printers).

Daniel

[Daniel Drake]

Please keep the list on CC

Wow! An incredibly complete answer to all things in detail. I really
appreciate that. (It's good enough to include as part of the official
project description I would think.)
So basically, the data from the files are fed to the fingerprint reader
and then it returns boolean information? Simple and powerful... mostly
simple.

Yes

If the specs for the fingerprint reader's protocol were made available
to you, you'd be able to plan future versions to make use of the gallery
scenario? I wonder who I might be able to talk to about this? Perhaps
I'll dig around a bit.

I've tried to contact UPEK as have others, they aren't interested. It
should also not be too difficult to reverse engineer it rather than faff
around with NDAs etc. At least for me the problem is having too many
other priorities first :)

I think it is very fortunate that most laptops are using this particular
device. This type of authentication is perfect for laptops in its
present form really. (Though I wonder what I will need to tweak to make
it work with my gnome keychain... it still wants a password only) But
in addition to the one connected to my laptop, I also have two of these
devices in stand-alone USB form. I have observed that the software only
sees or acts against one (usually the first one) it sees. I wonder if
the code could be tweaked to work with multiple devices? I haven't
really thought of a good reason to do that yet, but I thought it'd be
kind of interesting for testing and playing.

I'm not involved with thinkfinger development but I did adapt the code
and include it in my own project: http://www.reactivated.net/fprint

I'm working on developing the system enough so that we do have decent
integration with things like gnome-keyring. Takes time as we need to add
various layers of abstraction to make things work well, and a lot of new
code (including a new libusb) needs to be stabilised.

Daniel

[Christian Neumair]

Post by Daniel Drake
In this case, the device does image processing *in hardware*
and the protocol we use simply gives us a "yes" or "no" answer for
verification - it doesn't present us with images. This means that we're
constrained to the limits of the protocol (and/or our limited
knowledge
of it).

I've got no possibility to test all of this now, but isn't the
thinkfinger.bir file a unique hash of a given fingerprint? If it is, it
would just be

1) acquire fingerprint, store it to /foo/bir

2)

for user in gallery-group
if $HOME/.thinkfinger.bir == /foo/bir
return user

return 0

The problem is IMO that complex scenarios like this require a daemon,
which seems to be out of scope for thinkfinger.

best regards,
Christian Neumair

[Daniel Drake]

Post by Christian Neumair
I've got no possibility to test all of this now, but isn't the
thinkfinger.bir file a unique hash of a given fingerprint?

No. It's generated only in enrollment mode after 3 successful stages
(and is not a hash but a complete data structure representing a
fingerprint).

Daniel