Bug 205914

Created attachment 135926 [details]
Patch to support non-password pam authentication

Well, I have read
http://www.thinkwiki.org/wiki/How_to_enable_the_fingerprint_reader#Make_xscreensaver_use_the_scanner


I don't know about fingerprint pam module, however, for xscreensaver
side, it will be sufficient for this issue that xscreensaver supports
a non-password PAM authentication support.

A patch attached is applied in 5.00-21. Please verify this.

Created attachment 135927 [details]
Patch to support non-password pam authentication (modified)

Well, the previous patch is wrong.
New patch (attached) is applied in -22.

Now -22 is building. If it is done, the new rpms should be
obtained on 
http://buildsys.fedoraproject.org/plague-results/fedora-development-extras/xscreensaver/

Excellent. That package works great here with the fingerprint reader... 

Thanks so much for a quick and effective response! :) 

I'm sorry to say, that is a terrible way to accomplish this: it requires the user to set a magic preference, 
instead of the system figuring it out on its own.  If that preference is set, but the user is not (or is no 
longer) using a fingerprint reader, then they won't be able to unlock the screen at all. 

I won't be applying this patch upstream.  It needs to be more automatic than that.

Yeah, It would be nice if there was some way to autodetect this...

It's not the case that if they aren't using a fingerprint reader anymore they 
can't unlock the screen though. If they swipe an invalid fingerprint or the
fingerprint reader device is not available anymore, the regular password dialog 
comes up next, giving them a chance to use a password. (I inadvertently tested 
this as the permissions were wrong on my fingerprint reader usb device files at 
first and only the password dialog would show up). 

I suppose you could see if pam_bioapi was in the pam.d/* files, but that seems 
cludgy too. Does pam have any way to query it for capabilities?

The right way to do this is probably to have the passwd prompt dialog be under the PAM layer, instead of 
the other way around as it is now; but that's a pretty tricky restructuring of a complicated and security-
sensitive piece of code (that also has to work on non-PAM systems).  Someone sent me a patch once that 
tried to do that, but it was hard to understand and duplicated a lot of code, so I didn't do anything with it.

Given that I get a complaint about this problem about once every two years, I think the number of people 
using fingerprint readers is approximately zero (and I am not one of them) so I haven't had much incentive 
to do the (not insignificant) work needed to do this right.

(In reply to comment #4)
> I'm sorry to say, that is a terrible way to accomplish this: 
> it requires the user to set a magic preference, 
> instead of the system figuring it out on its own.  
> If that preference is set, but the user is not (or is no 
> longer) using a fingerprint reader, then they won't be able 
> to unlock the screen at all. 
> 

Well, my opinion is, it is the duty of sysadmin to set the parameter
of xscreensaver correctly.
Anyway sysadmin has to edit /etc/pam.d/xscreensaver (or 
/etc/pam.d/system-auth) if sysadmin want to use fingerprint as authentication
method, and xscreensaver should NOT automatically use fingerprint pam
module when available, it can be the case that sysadmin don't want to 
use fingerprint pam module even if it is available.

My patch pops up password window by default.
A. when forbid_passwin is set as True, password window does not appear,
B. when pop_passwin_iffailed is set as True, password window will appear
   if non-password pam authentication failed (pop_passwin_iffailed has
   no sense is forbid_passwin is set as False)

Today I will upgrade xscreensaver to 5.01. At this time I plan
to complete _DROP_ non-password pam auth until the following question is
solved.

Well, on the discussion of Jamie and me:
Jamie said:
-----------------------------------------------------------------------------
I don't think any of this passwordless stuff is going to work very well without
re-structuring the code to call PAM first, because PAM is a state machine that
engages in a *dialog* with the user.  Your patch assumes that something like
this happens:

  - user moves mouse to unlock screen
  - PAM says "I see a fingerprint, it is good"
  - screen unlocks.

Well, that assumes the user already has their finger on the reader (or has their
USB dongle plugged in, or whatever) before they move the mouse.  If they don't,
then what happens is:

 - user bumps mouse
 - password dialog comes up
 - user puts their thumb on the reader
 - nothing happens
 - user hits RET without removing their thumb
 - user moves mouse again
 - now it unlocks.

That's just about as bad as how it works today.... it doesn't sound like much of
a fix to me.


How the old (current) code works is this:

   - user bumps mouse;
   - pop up dialog box, and wait for password to be typed;

   - pam_start (user = jwz ...)
      - pam_authenticate (pass = thepassword ...)
         - that calls our pam_conversation() with: PAM ECHO_OFF, "Password: "
         - our pam_conversation() function ignores that,
           and returns the password we already read;
      - pam_authenticate() validates that password;
   - pam_end ()
   - we take down the password dialog and unblank.

How it should work is this:

   - pam_start (user = jwz ...)
      - pam_authenticate (nothing)

        - if we have a fingerprint reader:
           - that calls our pam_conversation() with:
             PAM_TEXT_INFO, "Place thumb on fingerprint reader: "
           - we pop up an alert with that text in it;
           - once the user does so, pam_authenticate() returns.

         - if we don't have a fingerprint reader:
            - that calls our pam_conversation() with:
              PAM_ECHO_OFF, "Password: "
            - we pop up the password dialog box, and wait for the text.

      - pam_authenticate() validates the password;
      - we take down the alert dialog, if any;
   - pam_end ()
   - unblank.


At least, I *think* that's how it would/should go.  I don't know, because I
don't have a fingerprint reader, and I have no idea how their PAM modules and/or
device drivers are actually implemented.

I think we should not apply your patch, because A) it doesn't solve the problem
well, and B) it will prevent the problem from ever getting solved correctly. 
----------------------------------------------------------------------------

Then I replied:
----------------------------------------------------------------------------
In fact I have the _SAME_ question. Currently we have to type a key or move
a mouse to invoke pam conversation. So, to use fingerprint method correctly,

* first fingerprint method must do something like "moving a mouse" or "type a
  key" when fingerprint method was invoked (i.e. fingerprint method should send
  a message that "fingerprint auth requested" to xscreensaver and xscreensaver
  should catch it). Currently, IMO, there is no other way than to move a mouse
  or type a key to invoke fingerprint auth anyway.
* Then xscreensaver try to non-passwd pam auth for the first time.

Well, if we want to fingerprint auth and try to use fingerprint machine, however
it won't begin without moving mouse, it is perhaps _NOT_ what we want to do.
-------------------------------------------------------------------------------

So, Kevin, could you explain what is happening when you're using
non-password (like fingerprint) auth on xscreensaver?

>So, Kevin, could you explain what is happening when you're using
>non-password (like fingerprint) auth on xscreensaver?

Sure, what happens is this: 

- I hit a key or move the mouse. 
- xscreensaver unblanks. 
- The fingerprint reader dialog comes up. It's a box that has a picture of a 
hand swiping a finger over the reader and says in text at the bottom: 
"swipe finger". 
- You swipe your finger. It shows a hourglass and then if it's a valid 
fingerprint that you enrolled, it shows a big green checkmark and unlocks the 
screen. 
- If you swipe your finger too fast it shows a arrow with a bunch of dashes, or 
if you swipe off center it shows a fingerprint with jags in it and then shows a 
big red X and doesn't unlock. 

I think Jamie is right on how it should work, except that the pam_bioapi module 
seems to handle the query for the fingerprint itself.  
basically pam_authenticate just says: "hey pam, someone wants to auth, do that 
for them" and has no way of knowing if that application will require a 
password, a fingerprint scan or what... 

from the pam_authenticate man page: 
"       The pam_authenticate function is used to authenticate the user. The user
       is required to provide an authentication token depending upon the
       authentication service, usually this is a password, but could also be a
       finger print."

It's worth noting that if there is not a DISPLAY set and a fingerprint is 
required (like at a console). It will just say "please swipe fingerprint" in 
text, etc. 

Does that help any? 

Well, Jamie, what do you think of this?

Note: I just built xscreensaver-5.01-1 and currently I _DISABLED_
non-password authentication (the patch for it exists in src.rpm, however,
I have not applied it for 5.01-1 now).

Ok, so with the module you're using, it's not quite as bad as I thought, but I think we can't assume that 
the fingerprint reader will pop up such a dialog -- that's exactly what PAM_TEXT_INFO and friends are 
for in the `conversation' callback function inside pam_authenticate().

When you run xscreensaver with -verbose, what PAM-related lines get logged when you auth using the 
fingerprint reader?

> "hey pam, someone wants to auth, do that 
> for them" and has no way of knowing if that
> application will require a  password, a
> fingerprint scan or what... 

Yes, but the conversation function is supposed to be an API whereby the PAM module can have an 
arbitrarily complex interaction with the user -- for example, it might ask you for a fingerprint *and* a 
password, one after the other.  (It would do this by calling the conversation callback multiple times 
before pam_authenticate returned.)  This wouldn't be a contrived thing for it to do, either: "something 
you have, plus something you know" is the principle usually employed by people who are serious about 
biometrics.

here's xscreensaver -verbose output: 

xscreensaver: 09:55:40: 0: suspending pid 24865 (lavalite)
xscreensaver: 09:55:40: pam_start ("xscreensaver", "kevin", ...) ==> 0 (Success)
xscreensaver: 09:55:40:   pam_set_item (p, PAM_TTY, ":0.0") ==> 0 (Success)
xscreensaver: 09:55:46:   pam_authenticate (...) ==> 0 (Success)
xscreensaver: 09:55:46:   pam_acct_mgmt (...) ==> 7 (Authentication failure)
xscreensaver: 09:55:46:   pam_setcred (...) ==> 0 (Success)
xscreensaver: 09:55:46: pam_end (...) ==> 0 (Success)
xscreensaver: 09:55:46: 0: resuming pid 24865 (lavalite)
xscreensaver: 09:55:46: unblanking screen at Tue Sep 19 09:55:46 2006.
xscreensaver: 09:55:46: 0: killing pid 24865 (lavalite)
xscreensaver: 09:55:46: unfading...
xscreensaver: 09:55:46: 0: child pid 4865 (lavalite) terminated with signal 15.
xscreensaver: 09:55:47: unfading done.
xscreensaver: 09:55:47: 0: ungrabbing mouse (was 0x4d).
xscreensaver: 09:55:47: 0: ungrabbing keyboard (was 0x4d).
xscreensaver: 09:55:47: 0: unlocked mode switching.
xscreensaver: 09:55:47: starting de-race timer (10 seconds.)
xscreensaver: 09:55:47: awaiting idleness.

I thought that the application didn't need to know the details of the auth, but 
It sounds like I am wrong. ;) 

Indeed, you can change the pam.d/xscreensaver entry to make the pam_bioapi 
'required' instead of 'sufficent' and make the password pam module also 
'required' to need both. I'm just not sure how much of that the application has 
to interact with... 

FYI, there is now a GPLed fingerprint reader program, which I just reviewed and
approved for fedora. The above patch doesn't seem to work with it. ;( 

Website: http://thinkfinger.sourceforge.net/
Package review: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=229291

I'd be happy to test out any potential solutions you guys have. ;) 

Is this solved by 5.02?

In reply to comment #14: 

No, it doesn't seem to be. With 5.02 I see the regular dialog for
username/password and swiping the fingerprint reader doesn't do anything. 

Is there any config I would need to set to get it working with the fingerprint
reader? I looked at the docs, but didn't see any mention except in the
changelog... "Reworked PAM code to support fingerprint readers, etc."

Happy to assist in debugging, just let me know what to try and/or what info to
provide. 

If you have a PAM config that knows about your fingerprint reader (e.g., if logging in on the console uses 
the fingerprint reader instead of prompting you for a password) then it should all work fine, since it's 
using exactly the same mechanism now.  Compare the "auth" entries in /etc/pam.d/xscreensaver and /
etc/pam.d/login.

Sorry for the delay... I had a chance to test this tonight. 

I get the regular xscreensaver unlock window asking for username/password. 
Swiping the fingerprint reader doesn't have any effect. 

My /etc/pam.d/xscreensaver is: 

--cut--
#%PAM-1.0

# Fedora Core 5:
auth       include      system-auth
--cut--

and my /etc/pam.d/system-auth is: 

--cut--
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      pam_env.so
auth        sufficient    pam_thinkfinger.so
auth        sufficient    pam_unix.so nullok try_first_pass
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        required      pam_deny.so

account     required      pam_unix.so
account     sufficient    pam_succeed_if.so uid < 500 quiet
account     required      pam_permit.so

password    requisite     pam_cracklib.so try_first_pass retry=3
password    sufficient    pam_unix.so md5 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

session     optional      pam_keyinit.so revoke
session     required      pam_limits.so
session     required      pam_unix.so
--cut--

I can use the fingerprint reader to login on the console or via gdm just fine. 

Someone else who was having trouble said that the cause was that the "thinkfinger" module doesn't work 
unless the caller is running as root, and that this made it work:

chmod 644 /etc/pam_thinkfinger/*.bir
chmod 755 /etc/pam_thinkfinger

I don't know what the security implications of that would be.  But the only way this is ever going to work is 
if all the relevant PAM modules allow authentication when invoked as a non-root user, because even when 
it is setuid, xscreensaver disavows its root privs long before PAM is ever invoked.

Odd. That doesn't seem to help it any here... 

The regular username/password dialog shows up, and swiping the fingerprint
reader doesn't seem to do anything. ;( 

Ah ha. Looks like pam_thinkfinger also can't talk to the usb device running as a
non root user: 

May 18 10:55:52 ningauble unix_chkpwd[27922]: password check failed for user (demo)
May 18 10:55:52 ningauble xscreensaver: pam_unix(xscreensaver:auth):
authentication failure; logname
= uid=501 euid=501 tty=:0.0 ruser= rhost=  user=demo
May 18 10:55:56 ningauble xscreensaver: pam_thinkfinger(xscreensaver:auth):
Could not claim USB device.
May 18 10:56:41 ningauble xscreensaver: pam_thinkfinger(xscreensaver:auth):
Could not claim USB device.

Sure enough, doing a 'chmod 666 /proc/bus/usb/003/003' causes it to work. 

So, I think xscreensaver is all working, we just need to get thinkfinger to work
as a regular user. ;) 

Thanks for all your great work on this. 

Okay. Now "for xscreensaver side", I close this as
rawhide.