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.
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
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?
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.
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?
(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).
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.
*** Bug 490332 has been marked as a duplicate of this bug. ***
This is fixed when using gdm.
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).
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:
*** Bug 508958 has been marked as a duplicate of this bug. ***
(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.
Isn't this bug a dupe of 500338 now?
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:
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.
Just for the reference: for gnome-screensaver this is bug #500338.