Bug 475810

Summary: Allow to enter password without waiting out the timeout
Product: [Fedora] Fedora Reporter: Matthias Clasen <mclasen>
Component: gnome-screensaverAssignee: jmccann
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 11CC: belegdol, bnocera, ccecchi, cschalle, jmccann, jonathan, kolyshkin, michael.monreal, palo.simo, rstrode
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-06-28 10:55:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matthias Clasen 2008-12-10 15:58:24 UTC
Basically, we want the text to be 'Swipe your finger or enter your password', and show the entry. Ray says this can be made to work by having the fprint pam module ask for password input, and set the pam item with the password if it is provided, and then fall through to the next module in the stack instead of signalling success. The pam unix module needs to have some option set in the pam config to actually use a password that is provided in this way.

Ray can tell you more details.

This bug probably really belongs to authconfig, since it needs to write out the right pam configuration.

Comment 1 Ray Strode [halfline] 2008-12-10 18:01:14 UTC
you basically do

pam_info (handle, _("Please swipe finger or type password"));
pam_prompt (handle, PAM_PROMPT_ECHO_OFF, &password, _("Password"));

then set the result with pam_set_item (handle, PAM_AUTHTOK, password) and return with PAM_IGNORE.

Then in the pam stack (this is where authconfig comes in) you run pam_unix with try_first_pass if PAM_IGNORE was returned from pam_fprint

Comment 2 Bastien Nocera 2008-12-18 09:17:32 UTC
Isn't pam_prompt blocking? pam_fprintd isn't threaded, nor should it be, so how can I ask for the password without blocking? Is there a better pam_prompt() function that could be integrated in a mainloop?

Comment 3 Ray Strode [halfline] 2008-12-18 17:39:02 UTC
right, so maybe this approach isn't viable for you after all.

For the smartcard case what we did was restart the pam conversation on the gdm/screensaver side anytime a smart card got removed or inserted.

You could do something similar but it would mean patching gdm and screensaver.  Sorry, forgot about that detail.

Comment 4 Pavol Šimo 2009-01-21 09:38:11 UTC
Now I use thinkfinger module for pam authentication with these two lines:

auth        sufficient    pam_thinkfinger.so debug
auth        sufficient    pam_unix.so try_first_pass nullok

(I think only the first one was added by myself)
The prompt reads "Password or swipe finger" and I may type the password or swipe finger without any timeout or so...
So I think the pam_thinkfinger module does the "right thing" - what about looking into its sources?

Comment 5 Bastien Nocera 2009-01-21 10:44:46 UTC
(In reply to comment #4)
> Now I use thinkfinger module for pam authentication with these two lines:
> 
> auth        sufficient    pam_thinkfinger.so debug
> auth        sufficient    pam_unix.so try_first_pass nullok
> 
> (I think only the first one was added by myself)
> The prompt reads "Password or swipe finger" and I may type the password or
> swipe finger without any timeout or so...
> So I think the pam_thinkfinger module does the "right thing" - what about
> looking into its sources?

It doesn't do the right thing. It uses gross hacks to achieve that goal, and those hacks shouldn't be repeated (it creates threads, which aren't allowed in PAM, and it feeds the kernel fake key events which would wreak havoc on a lot of setups).

Comment 6 Ray Strode [halfline] 2009-01-22 14:47:06 UTC
So i'm working on making gdm support multiple simultaneous PAM stacks.  if that works out, it could solve this problem in a fairly nice way.

Comment 7 Michael Monreal 2009-03-15 13:42:15 UTC
*** Bug 490332 has been marked as a duplicate of this bug. ***

Comment 8 Bastien Nocera 2009-04-22 16:19:48 UTC
This is fixed when using gdm.

Comment 9 Jonathan Dieter 2009-06-03 09:26:54 UTC
Though not for gnome-screensaver.  I still have to wait 30 seconds before I can type in my password when unlocking my computer (or, more accurately, my wife has to when she want to use my computer as my thumbprint works fine).

Jonathan

Comment 10 Bug Zapper 2009-06-09 10:12:55 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle.
Changing version to '11'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 11 Bastien Nocera 2009-06-30 17:06:08 UTC
*** Bug 508958 has been marked as a duplicate of this bug. ***

Comment 12 Bastien Nocera 2009-06-30 17:08:54 UTC
(In reply to comment #9)
> Though not for gnome-screensaver.  I still have to wait 30 seconds before I can
> type in my password when unlocking my computer (or, more accurately, my wife
> has to when she want to use my computer as my thumbprint works fine).

You could enroll another fingerprint using fprintd-enroll, depending on the type of device you have (if it's an imaging device, otherwise, it'll only work with one print).

As PAM is unlikely to disappear in the short-term, Ray should apply his GDM magic to gnome-screensaver to make it multi-stack as well. Moving to gnome-screensaver.

Comment 13 Julian Sikorski 2010-01-05 21:48:03 UTC
Isn't this bug a dupe of 500338 now?

Comment 14 Bug Zapper 2010-04-27 12:30:20 UTC
This message is a reminder that Fedora 11 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 11.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '11'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 11's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 11 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 15 Bug Zapper 2010-06-28 10:55:58 UTC
Fedora 11 changed to end-of-life (EOL) status on 2010-06-25. Fedora 11 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 16 Kirill Kolyshkin 2010-10-28 11:53:22 UTC
Just for the reference: for gnome-screensaver this is bug #500338.