libpam-gnome-keyring: keyring password should be updated or cleared when a new system password is used

[Alex Mauer]

Binary package hint: libpam-gnome-keyring

On a system set up to authenticate to an external service, such as LDAP, Active Directory, or Kerberos: When the password is changed on the external service (e.g. due to a forgotten password+reset or a forced periodic password change where the user happened to log in on a different machine when the change came due), the keyring is not unlockable with the new password. This means that unless the user remembers their old password, and knows how to change the keyring password, the keyring must be wiped, losing all the keys stored in the keyring.

This bug is distinct from several other similar bugs, in that it the other bugs relate to the keyring password not being updated properly when the password is changed on the current system. This one concerns only the situation where the password is changed externally.

One possible (but very ugly) solution is to simply drop the current keyring/passphrase and start anew when the user successfully logs in using a password that doesn't unlock the keyring. Better would be to somehow change the keyring password so that the keyring can be unlocked with the new password.

This is in Ubuntu Jaunty.

[Sebastien Bacher (seb128)]

Thanks for the bug report. This particular bug has already been reported, but feel free to report any other bugs you find. The passwd pam configuration needs to be updated there is a bug open already about that request

[Sebastien Bacher (seb128)]

the bug is similar to the other requests and not a gnome-keyring issue but the job of the tools used to change the password rather

[Alex Mauer (hawke)]

This is not the job of the tools used to change the password. It is not the responsibility of say, "Active Directory Users and Computers" or "ldappasswd" or "kpasswd" to know that libpam-gnome-keyring is used on some arbitrary machine elsewhere and somehow go and change the keyring password on that other machine. It is clearly the responsibility of gnome-keyring to handle the situation gracefully when the password has been changed elsewhere, outside of its control.

[Sebastien Bacher (seb128)]

what do you suggest? there is no reason the gnome-keyring password and the login one should be identical and gnome-keyring can read the user password since that would mean this one would be stored in clear somewhere

[Alex Mauer (hawke)]

By default, libpam-gnome-keyring unlocks the gnome keyring using the login password, correct?

I see no reason that this should stop working just because the user's login password was changed.

[Sebastien Bacher (seb128)]

> libpam-gnome-keyring unlocks the gnome keyring using the login password, correct?

not really no, libpam-gnome-keyring try to unlock the gnome-keyring using the password that you typed, if you happen to have the same password for login and gnome-keyring that works but otherwise that doesn't

[Alex Mauer (hawke)]

Fair enough, it *attempts* to open the keyring with the login password. On a fresh install of Ubuntu, the passwords are the same, so the process is invisible to the user until the password is changed.

[Sebastien Bacher (seb128)]

how would you suggest it to know about system password changes and the new password to use?

[Alex Mauer (hawke)]

It would know about the password change because the password wouldn't work to unlock the keyring. The new password would obviously be the new user login password.

[Sebastien Bacher (seb128)]

nothing force the use of a similar password for the login and ngome-keyring so unlocking not working would not mean that the password change, there is also no automatic way to read a password or it would mean the storage would not been secure since another software could read and copy it for example

[Alex Mauer (hawke)]

I agree that nothing forces the use of a similar password. However, it is the default on a fresh Ubuntu install.

One possibility would be for gnome-keyring to have a configuration flag that would indicate if the password should be synchronised with the system password. No cleartext stored password should be necessary.

So the sequence would go:
1. On an Ubuntu fresh install the password sync flag would be set, and keyring password would be the same as the login password.
2. User's password is changed externally.
3. User logs in. The password is accepted for login, but does not unlock the keyring.
4. libpam-gnome-keyring has the new password since the user just logged in with it.
5. libpam-gnome-keyring needs the old password, so it prompts for it.
6. libpam-gnome-keyring changes the keyring password and unlocks the keyring.
7. The user changes the keyring password manually.
8. The password sync flag is cleared, and so libpam-gnome-keyring should no longer do steps 5 and 6.

[Alex Mauer (hawke)]

Oh, and:
5b. If it's not possible to prompt for the old password like this, remove the keyring entirely and create an entirely new one with the new password.

[Sebastien Bacher (seb128)]

reopening as a wishlist request

[Peter Frost (slimeypete)]

Having just fallen foul of this myself, I thought it worth noting that the keyring password prompt on Intrepid specifically asks for the *login* password. This is very confusing because what it actually wants is the keyring password, which won't be the same once the user has changed their login password. If the prompt hasn't been changed in Jaunty, it probably should be.

[SK (s7388)]

I just added bug #376225 before finding this. I'll leave it to others to decide whether to mark as a duplicate, since this bug is supposedly about LDAP, Active Directory, or Kerberos also.

However, I think I can contribute to this discussion.
Sebastien Bacher wrote:
> how would you suggest it to know about system password changes and the new password to use?

The mechanism has already existed at one point, see /usr/share/doc/gnome-keyring/README.Debian. It suggests you add the following line to /etc/pam.d/common-password:
password optional pam_gnome_keyring.so

I tried this and it does not work, it must have been broken at some point. To fix this bug, I suggest you fix this feature, and make it the default.

I'd also like to say, however, that I feel marking this bug as "Wishlist" is inappropriate. Two people I know spent months being forced to type their old, long-obsoleted passwords just so NetworkManager would allow them on their wireless network. This is a bug.

Sebastien Bacher wrote:
> not really no, libpam-gnome-keyring try to unlock the gnome-keyring using the password that you typed, if you happen to have the same password for login and gnome-keyring that works but otherwise that doesn't

Then this behavior should be changed, it's as simple as that. You're talking about preserving a severe usability issue, for the sake of a feature that is completely useless to almost anybody. You could consider following Alex Mauer's step-by-step suggestion to keep the option available. Otherwise, just forget about it, and tie the login keyring to the login password. No one will mind and many will be helped.

[Odin Hørthe Omdal (velmont)]

I've tried every password I've ever thought about, but I still can't make Evolution function as I don't know how that keyring came into being.

My user was never created on this machine, as they are created on the server where no fancy-pants keyrings exist. So I guess Ubuntu just made one the first time I logged in and used NULL as password or something, because it's impossible to unlock it.

[David Burke (bufke)]

Still present. Has anyone found a work around? This is a potential show stopper for a Linux deployment if users happen to need the password for anything important. Forcing all users to use unsafe (passwordless) storage would be an acceptable solution.

Right now I'm working around it by going to EVERY user and setting it to unsafe storage. It's highly annoying with 50 users, it wouldn't be a solution for any larger deployment. I don't see anyway to use gnome without the keyring manager either.

I tried setting a unsafe password then copying .gnome2/keyrings to a new user. This didn't work. Surely there must be some way of doing this.

[Stephane Chazelas (stephane-chazelas)]

Related redhat bug: https://bugzilla.redhat.com/show_bug.cgi?id=975469