After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 587164 - pam_gnome_keyring must have use_authtok option
pam_gnome_keyring must have use_authtok option
Status: RESOLVED FIXED
Product: gnome-keyring
Classification: Core
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2009-06-27 23:56 UTC by Matthias Clasen
Modified: 2009-07-09 02:08 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Possible patch (1.65 KB, patch)
2009-06-28 18:17 UTC, Stef Walter
none Details | Review
Complete patch (1.98 KB, patch)
2009-06-29 20:10 UTC, Stef Walter
none Details | Review

Description Matthias Clasen 2009-06-27 23:56:18 UTC
From https://bugzilla.redhat.com/show_bug.cgi?id=443960

am_gnome_keyring.so module must recognize the use_authtok option in
pam_sm_chauthtok. When this option is specified it must not ask for the new
password through the conversation function. It must just try to get it by
pam_get_item(pamh, PAM_AUTHTOK,...). If the returned item is NULL it should fail
with the PAM_AUTHTOK_RECOVERY_ERR.
The module should also call pam_set_item(pamh, PAM_AUTHTOK, NULL) in case it is
failing due to other reasons.
Comment 1 Stef Walter 2009-06-28 18:17:51 UTC
Created attachment 137511 [details] [review]
Possible patch

Here's a possible fix for this problem. 

However since I'm not a PAM expert, I won't be committing this without the go ahead from the original poster of the problem or someone knowledgeable in this area.

In particular I don't understand the full effects of clearing the PAM_AUTHTOK when an error occurs.
Comment 2 Matthias Clasen 2009-06-28 18:41:20 UTC
Stef, thanks for the quick action. I'll ask tmraz to have a look at your patch (he's our pam master)
Comment 3 Tomas Mraz 2009-06-29 10:16:07 UTC
I don't see the code to parse the use_authtok option in the patch. But otherwise it looks good.
Comment 4 Stef Walter 2009-06-29 20:10:55 UTC
Created attachment 137581 [details] [review]
Complete patch

Sorry about the missing bit of code. Still getting completely used to git ...

I want to ask though, why would we clear the PAM_AUTHTOK when an error occurs? Does that mean if gnome-keyring isn't working for some reason, then the user can't change their password?
Comment 5 Tomas Mraz 2009-06-30 06:42:35 UTC
Yes, but you can prevent that by putting pam_gnome_keyring at the end of the PAM stack.

It might be considered whether it should clear the PAM_AUTHTOK in all cases. For example if the user does not have keyring at all it should not clear the PAM_AUTHTOK. Basically it makes sense to clear the PAM_AUTHTOK if the error is intermittent and the user might be able to do something about it and retry changing the password. On the other hand if the failure is permanent it should not block other modules to change the password.
Comment 6 Stef Walter 2009-07-09 02:08:26 UTC
Committed. 

I left out the part that sets PAM_AUTHTOK to NULL. We'd really really like the login keyring password to track the user's unix password. But this is not a good enough excuse to prevent the user changing their unix password. 

The entire process is not bullet proof, in any case. For example if root changes the user's password then we can't change the keyring password (no PAM_OLDAUTHTOK). In the cases where the keyring password is out of sync with the unix password, the user will get prompted. Incidentally this is the behavior of other OS's as well (Mac OS X for example).