GNOME Bugzilla – Bug 587164
pam_gnome_keyring must have use_authtok option
Last modified: 2009-07-09 02:08:26 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.
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.
Stef, thanks for the quick action. I'll ask tmraz to have a look at your patch (he's our pam master)
I don't see the code to parse the use_authtok option in the patch. But otherwise it looks good.
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?
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.
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).