gnome-keyring passwd should be changed on system password change

[Otto Kekäläinen]

Impact:
Leads to have login and desktop passwords out of sync which triggers confusing password prompts for users (need to enter their old login password)

Test Case:
1. Install a fresh Ubuntu
2. Log in and connect to a password protected WLAN (and thus save a password in the Gnome keyring)
3. Log in again and change the password of the user using System > User info > Change password
4. Log in again. Now the Gnome keyring complains that it was unable to open. The computer is not connected to the protected WLAN and the user is asked both the Gnome keyring password and the WLAN password.

Regression potention:
Check that the keyring password is correctly updated

Better description and fresh follow-up in report https://bugs.launchpad.net/ubuntu/precise/+source/gnome-control-center/+bug/911426

Original description:

The default Gnome keyring manger in Ubuntu 9.04 (Seahorse 26.6.1?) asks the user to unlock his/her keyring in order to save the Ubuntu One token _if_ the user has changed his/her password after initial installation/login of Ubuntu 9.04.

The actual problem seems to be that the default password for the keyring is initially and automatically set to the same password the user uses to log in into Ubuntu (GDM). The user does not know anything about the keyring, because it works automatically (and that's fine). However if the user ever changes his/her password for Ubuntu (Linux username) the password protecting the keyring is not changed. So later if the user needs to unlock the keyring, he/she needs to rembember what was his/her password when he/she started using Ubuntu in the beginning.

The solution would be to set some kind of flag in the Gnome keyring (Sea Horse?) that the password has been taken automatically from the username/login. So if ever the user does change his username/login password, the Gnome keyring would know to automatically also change the password that protects the keyring.

This bug does not effect new users of Ubuntu, but most likely everybody who has been using Ubuntu for a longer time (and thus has changed their login password at some time, which brakes the keyring automatics).

[Paul Sladen (sladen)]

The PAM entry in

  /etc/pam.d/gdm

contains a call to:

  libpam-gnome-keyring.so

to unlock the keyring. The keyring should also be re-encrypted at password-change time.

[Otto Kekäläinen (otto)]

According to site http://live.gnome.org/GnomeKeyring/Pam
"When the user changes their password, the PAM module changes the password of the 'login' keyring to match.
 * Again, here gnome-keyring-daemon is started if necessary.
 * If root changes the password, or /etc/shadow is directly edited then due to the lack of the old password, the 'login' keyring cannot be updated."

It seems as if this didn't happen on my Ubuntu 9.04. I am not running root, just a regular user (but with admin rights).

[Matthias Niess (mniess)]

I can confirm this for a fully updated lucid. If I use GUI-tools to change the password ('users and groups' or 'personal information') only the login-password will be changed. If I run passwd as the user in a terminal, the PAM module is called and it changes the login-keyring password, too. The bug is probably rather in the GUI-tools.

[Kenrick Bingham (loxo)]

On Ubuntu 10.04 (lucid):

The login keyring password seems to be changed together with password change if I run "passwd" in a terminal in a Gnome session.

The login keyring password is not changed if I change my password in gnome-about-me (System - Preferences - About Me - Change Password) or by running "passwd" in an ssh session.

[John O'Brien (jdobrien)]

I am experiencing something similar in Maverick beta

[Otto Kekäläinen (otto)]

Why was this bug marked invalid? On the contrary it has been very valid for years and it affects all users who change their password after initial system installation or user account creation.

Steps to reproduce:
1. Install a fresh Ubuntu
2. Log in and connect to a password protected WLAN (and thus save a password in the Gnome keyring)
3. Log in again and change the password of the user using System > User info > Change password
4. Log in again. Now the Gnome keyring complains that it was unable to open. The computer is not connected to the protected WLAN and the user is asked both the Gnome keyring password and the WLAN password.

Alternatively:
1. In an existing Ubuntu installation, create a new user.
2. Log in with the new user. Connect to Ubuntu One (and thus the Gnome keyring is initialized and the U1 password saved there).
3. Log in again and change the password of the user using System > User info > Change password
4. Log in again (with the new password). Now the Gnome keyring complains that it was unable to open. User is presented with a Gnome keyring password dialog and U1 does not connect to the network automatically as it used.

In both examples inserting the old user password into the Gnome keyring dialog opens it. Thus it can be concluded that the error happens in step 3: the keyring password should be changed to be the same as the login password, since it was like that by default earlier.

Normal users don't know anything about the Gnome keyring, so they freak when they are asked to enter a password again after logging in.

Surprisingly, most users newer change their initial password, so this bug affects a minority, but still we should not mess with those who actually want to protect their computer and goes trough the effort of changing their system password once in a while.

[Otto Kekäläinen (otto)]

Possible duplicates:
bug #644488, bug #162710, bug #597893, bug #473139, bug #496253, bug #575877, bug #268731, bug #600512, bug #643484.

I don't have time to investigate this further but I'm willing to pay a 100 € bounty to whoever commits the fix. Maybe this could even be marked as a papercut?

[Matthias Niess (mniess)]

Can someone please set an importance other than "undecided" or "whishlist"? All Ubuntu-users I know, suffer from this bug. Usually they change their password back to the old password.

This is not critical since there is a workaround (use passwd in a terminal), but this might be a papercut.

[Otto Kekäläinen (otto)]

Could somebody please look into this? I've seen newbie users suffer from this over and over again...

[Matthias Niess (mniess)]

Okay. So actually this bug IS invalid for gnome-keyring. All components of gnome-keyring ensure a password change will change the keyring-pw, too IF you use passwd.

But USERS use gnome-about-me or users-admin to change passwords. Neither of those change the password for gnome-keyring (or ecryptfs).

[Matthias Niess (mniess)]

According to the GNOME Bug:
"The 'about-me' dialog doesn't transfer the user environment variables to the
spawned 'passwd' (it transfers a void environment). The PAM keyring module
therefore can not connect to GNOME Keyring."
There's also an attached patch, but I don't know whether this went into the current release, yet (didn't have a chance to test).

[Andreas Heinlein (aheinlein)]

I assume what comment #11 describes is also the cause of a different but related scenario: password expiry (in a corporate environment). A PAM-forced password change also does not update the keyring password, presumably because there is no user session and thus no gnome-keyring-daemon yet. Is there any way around this, and where would this bug belong?

[Matthias Niess (mniess)]

I don't see this as a medium importance bug. People not being able to change their passwords is not of medium importance. And #12 is right. If you have password expiry in a corporate environment it is even worse. Fixing the linked gnome-bug should fix this, though.

[Tom Brito (brito-pro)]

solved it with:
 https://bugs.launchpad.net/ubuntu/+source/subversion/+bug/473139/comments/9

[Otto Kekäläinen (otto)]

Brito: that is just a workaround. Another option is to open Keyring manager, select the login group and change the password manually (enter first you old login password and then new login password). After that the login group we'll be automatically open then you log in.

However a workaround isn't the point in here. The point is that changing you password brakes your Ubuntu installation from a normal users point of view, since it "suddently" starts to ask about some password and the user has no clue about why. This is still valid in Lucid, I saw it last week again while helping out a newbie.

[Miguel Mendes Ruiz (migmruiz)]

reproduced here, need any testing?

[Sebastien Bacher (seb128)]

@Miguel: testing is ok, what is lacking is patches ;-)

[Sebastien Bacher (seb128)]

gnome-control-center (1:3.4.2-0ubuntu11) quantal; urgency=low

  * debian/control.in:
    - updated clutter requirement to match the configure version
  * debian/patches/96_sound_nua_panel.patch:
    - drop hacks and merge upstream changes for mouse scrolling (lp: #953757)
  * debian/patches/git_sound_sliders.patch:
    - "sound: Fix mouse scrolls on sliders"
  * debian/patches/git_update_keyring_password.patch:
    - "Fix login keyring password not getting updated" (lp: #416825)
  * debian/source_gnome-control-center.py:
    - updated for python3, thanks Edward Donovan (lp: #1013171)
  * debian/UbuntuLogo.png:
    - updated logo for 12.10 (lp: #1035501)

[Ritesh Khadgaray (khadgaray)]

debdiff for precise

This is being request by our customers.

[Martin Pitt (pitti)]

Thanks! Sponsored with fixed bug ref in the changelog.

[Sebastien Bacher (seb128)]

(I've rejected the upload to do a new one including some other changes that were commited in the vcs as well)

[Colin Watson (cjwatson)]

Hello Otto, or anyone else affected,

Accepted gnome-control-center into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/gnome-control-center/1:3.4.2-0ubuntu0.6 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Chris Halse Rogers (raof)]

Hello Otto, or anyone else affected,

Accepted gnome-control-center into precise-proposed. The package will build now and be available at http://launchpad.net/ubuntu/+source/gnome-control-center/1:3.4.2-0ubuntu0.7 in a few hours, and then in the -proposed repository.

Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users.

If this package fixes the bug for you, please change the bug tag from verification-needed to verification-done. If it does not, change the tag to verification-failed. In either case, details of your testing will help us make a better decision.

Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance!

[Sebastien Bacher (seb128)]

Could somebody who was having the issue confirm the fix?

[Matthias Niess (mniess)]

I don't have a machine with precise available at the moment. Anyone with precise can confirm the issue by using the testcase. Just change the password using the GUI tools and you won't have access to the Gnome keyring.

[Matthias Niess (mniess)]

I can at least confirm the problem doesn't exist in 12.10 anymore.

[Otto Kekäläinen (otto)]

Running 12.04 with ubuntu-proposed enabled, all updates installed as of 2012-12-05. I ran the test case described in the bug report and there was no error.

However, it seems that WLAN passwords are no longer stored in the Gnome keyring, but in Network-Manager, thus the example wasn't that good, but used the "change password" feature in Seahorse to look what the current password was, thus can confirm that this issue is now fixed.

You can now mark this as fixed!

[Sebastien Bacher (seb128)]

thanks for confirming the fix!

[Scott Kitterman (kitterman)]

The verification of this Stable Release Update has completed successfully and the package has now been released to -updates. Subsequently, the Ubuntu Stable Release Updates Team is being unsubscribed and will not receive messages about this bug report. In the event that you encounter a regression using the package from -updates please report a new bug using ubuntu-bug and tag the bug report regression-update so we can easily find any regresssions.

[Launchpad Janitor (janitor)]

This bug was fixed in the package gnome-control-center - 1:3.4.2-0ubuntu0.7

---------------
gnome-control-center (1:3.4.2-0ubuntu0.7) precise-proposed; urgency=low

  * debian/patches/git_unmute_sound_event.patch:
    - use the patch for sound-nua and Unity sessions as well (lp: #986692)

gnome-control-center (1:3.4.2-0ubuntu0.6) precise-proposed; urgency=low

  * debian/patches/git_unmute_sound_event.patch:
    - "sound: Make sure the event sound stream stays unmuted" (lp: #986692)
  * debian/UbuntuLogo.png:
    - updated logo for 12.04.1 (lp: #1041369)

  [ Ritesh Khadgaray ]
  * debian/patches/git_update_keyring_password.patch:
    gnome-keyring passwd should be changed on system password change
    (LP: #416825)
 -- Sebastien Bacher <email address hidden> Mon, 19 Nov 2012 11:46:46 +0100