GNOME Bugzilla – Bug 411293
thinkfinger (PAM) support
Last modified: 2007-07-08 17:38:05 UTC
+++ This bug was initially created as a clone of Bug #338635 +++
Is there any possibility for gnome-screensaver to incorporate bioapi support?
Actually, this bug report is about thinkfinger, which provides fingerprinting hardware support through PAM and a library.
It's open-source, and I think better integration could be done in gnome-screensaver itself.
Dup of 410853?
Note, I can't think of any reason that gnome-screensaver would need changes to support thinkfinger.
Yeah, the only difference might be that gnome-screensaver-dialog and test-passwd aren't privileged. So, there may be issues with access to the usb device and/or the finger print database.
If you run "sudo test-passwd" does it work or at least do something?
*** Bug 410853 has been marked as a duplicate of this bug. ***
It would be useful for gnome-screensaver to have a specific UI for fingerprint scanning. Ie. it would be nice if it knew you were trying to scan for a fingerprint and either failed or didn't have a fingerprint in the database.
If gnome-screensaver knew there was a fingerprint reader in the machine, it might ask to swipe in the fingerprint, as well as asking for a password.
Bastien: the PAM module does all that.
When I run it (with kludged permissions) I get a "Password or swipe finger:" prompt.
I confirm that there is a bug somewhere. Could you explain what you mean by "kludged permissions" ?
test-passwd works if I set the permissions to 644 in /etc/pam_thinkfinger (it's the directory where the fingerprint files are stored).
But gnome-screensaver-dialog doesn't show the "Password or swipe finger:" prompt and hangs somewhere. The buttons can't be pressed and I can't enter anything in the password field.
I'm using thinkfinger 0.2.3pre which uses uinput to "fake" a CR when authenticating via fingerprint succeeded.
I'm running g-s 2.16.1 on Ubuntu Edgy.
I think best way haw to add correct support for thinkfinger is to write BioAPI BSP for thinkfinger driver which enable using pam_bioapi itself. Because new version of pam_bioapi (0.4) calling all BioAPI functions with root privileges (from suid binary) it also solve all permissions problems.
(In reply to comment #9)
> I think best way haw to add correct support for thinkfinger is to write BioAPI
> BSP for thinkfinger driver which enable using pam_bioapi itself. Because new
> version of pam_bioapi (0.4) calling all BioAPI functions with root privileges
> (from suid binary) it also solve all permissions problems.
That's not any different from using an suid binary to do the authentication (which is what gnome-screensaver uses). Furthermore, why work around the problem by making it compatible with a proprietary library, when all the bits in thinkfinger are free software, and can be modified to do what we want?
It's indeed a permission problem. When swiping your finger under gnome-screensaver, it doesn't work at all but the following log occurs in auth.log :
Feb 25 11:38:38 spoutnik auth: pam_thinkfinger: pam_sm_authenticate() called.
Feb 25 11:38:38 spoutnik auth: pam_thinkfinger: user ploum is unknown.
Feb 25 11:38:38 spoutnik auth: pam_thinkfinger: pam_sm_authenticate returning 10 (User not known to the underlying authentication module)
(In reply to comment #10)
> Furthermore, why work around the
> problem by making it compatible with a proprietary library, when all the bits
> in thinkfinger are free software, and can be modified to do what we want?
pam_bioapi is also free software so I don't understand your argumentation. I also don't understand what you want to modify - HW is still HW, proprietary driver use defined standard to communicate with free software so only one thing Thinkfinger do is fragmentation of the solution for the problem. I do not have problem with that if Thinkfinger use also bioapi standard, but for every new driver use another pam module is I think very unlucky solution.
Created attachment 84736 [details] [review]
Ugly patch for pam_thinkfinger.c
(In reply to comment #13)
> Created an attachment (id=84736) 
> Ugly patch for pam_thinkfinger.c
This is very very ugly patch which "hide" prompt for gnome-scrensaver ,gdm etc.
Function pam_prompt() "hangs" executed by gnome-screensaver, and thread pam_promp_thread never ends.
Second problem is privilage on *.bir files. Gnome-screensaver uses $USER uid in pam module and after opening file in pam_thinkfinger_check_user() got permission denied.
This is easy to fix by changing ownership $USER.bir file to $USER
First, please do not add any hacks to either g-s or pam_thinkfinger.
The UPEK device supported by ThinkFinger is just one of many new authentication schemes we need to be prepared for. I am not only talking about fingerprint authentication. We also may want to support other authentication methods like voice recognition, iris scan, ear shape -- just to name a few.
So, if pam_bioapi claims to be some sort of an abstraction layer for all that, we should start working on that.
That still implies work on the PAM using applications such as g-s. And, g-s should be able to handle PAM modules like pam_thinkfinger. There's no rocket science within pam_thinkfinger. It's just a PAM module after all.
Is there any reason not to use a common authentication backend for g-s, gdm, gksu and friends? When I prepared the integration for ThinkFinger on SLED10 SP1 I was a little puzzled to see all the different implementations within GNOME.
Sorry for jumping in late.
I've sent a patch to the thinkfinger list that hopefully fixes the .bir file permission problem.
Having trouble testing the other problems because FC6 doesn't seem to have uinput.
Created attachment 84785 [details] [review]
patch for thinkfinger
Just for the record. Here is another patch that I just sent to the thinkfinger-devel list. It works well on FC6.
Thread with another patch update here:
So, I'm going to close this since support doesn't require any changes to gnome-screensaver. Hopefully upstream thinkfinger is receptive to my suggestions.
Actually, thread indices are here:
*** Bug 429830 has been marked as a duplicate of this bug. ***