update gnome keyring master password when user password is updated

Bug #268731 reported by ClemensBier
98
This bug affects 16 people
Affects Status Importance Assigned to Milestone
shadow (Ubuntu)
Confirmed
Wishlist
Unassigned

Bug Description

Binary package hint: gnome-control-center

1) lsb_release -rd
Description: Ubuntu 8.04.1
Release: 8.04

2) apt-cache policy gnome-control-center
gnome-control-center:
  Installiert:1:2.22.1-0ubuntu4.1
  Mögliche Pakete:1:2.22.1-0ubuntu4.1
  Versions-Tabelle:
 *** 1:2.22.1-0ubuntu4.1 0
        500 http://ports.ubuntu.com hardy-updates/main Packages
        100 /var/lib/dpkg/status
     1:2.22.1-0ubuntu4 0
        500 http://ports.ubuntu.com hardy/main Packages

3) Expected behavior:
When a user changes his login password via the "About me" dialog, the associated Gnome keyring master password should also be updated accordingly. The wanted functionality is equivalent to doing this sequence of steps:

   1. Download and install, either via synaptic or apt-get, the seahorse package. More information on this package is available at the Gnome Documentation Library;
   2. Start the application by clicking on the following menus: System -> Preferences -> Encryption Preferences;
   3. Click on the Gnome Keyring tab, on the far right, in the Encryption Preferences window;
   4. Enter your old password into the ‘Original Master Password’ field;
   5. Enter your new password into the ‘New Master Password’ field;
   6. Re-enter your new password into the ‘Confirm Master Password’ field;
   7. Click the ‘Apply’ button; and
   8. Close the ‘Encryption Preferences’ window.

4) What happens instead
The login password can be updated independently from the Gnome keyring master password. This creates a fancy pop-up window (requesting to unlock the Gnome keyring) every time you login requesting a password the user normally does not want to use anymore.

Revision history for this message
Sebastien Bacher (seb128) wrote :

the issue is a passwd one, the pam configuration should use gnome-keyring so the password is updated there too

Changed in gnome-control-center:
importance: Undecided → Wishlist
Revision history for this message
Geoff Goehle (goehle) wrote :

I'm adding some updates to this bug, but I've only been poking around for a day or so, so feel free to comment. First, this is currently a wishlist item but I'm going to argue that its a bug. Taking a look at the source for the PAM module in gnome-keyring it looks like pam_gnome_keyring.so supports the password service. (At least there is code in there for changing the keyring password when the login password is changed.) At this point it should just a matter of adding the line

password optional pam_gnome_keyring.so

to the appropriate config files in pam.d. (In particular passwd, but this should really include anything that uses PAM to change the login password. It could even be added to common-password, except I think this file is autogenerated by pam-auth-update.) So it should be a quick fix, but the problem is that it doesn't seem to work. By that I mean, if you sync the login and keyring passwords, then change the login password using passwd (after adding the above line to the passwd file in pam.d) then the keyring passwd remains unchanged. So the password service is implemented, but appears to be broken. I think the following bug may be relevent https://bugzilla.redhat.com/show_bug.cgi?id=250147. Also, I'm using how ecryptfs interacts with PAM as my model for how this should work, if that helps.

Revision history for this message
Geoff Goehle (goehle) wrote :

OK, so I made a newbie mistake. The "password optional pam_gnome_keyring.so" has to be added to the end of the passwd file so that its at the bottom of the stack and the usual unix stuff gets a chance to run first. The good news is that if you add "password optional pam_gnome_keyring.so" to the end of the passwd file, or to the end of common-password, then the keyring password *is* kept in sync with the login password. So its a super easy fix in any case.

Revision history for this message
Geoff Goehle (goehle) wrote :
Revision history for this message
Sebastien Bacher (seb128) wrote :

why did you reassign this bug to gnome-keyring? it was assigned to the source which ships the pam configuration to update which is correct

Revision history for this message
Geoff Goehle (goehle) wrote :

Sorry. Poor choice on my part after some consideration. I have a question though. It should be fine to include the appropriate line to passwd, even if libpam-gnome-keyring isn't installed, because its optional. But wouldn't it be better to change the install script of libpam-gnome-keyring to add the necessary configuration lines? I don't know much about the update/install/package process so this may be nonsense.

Revision history for this message
Piotr Morgwai Kotarbiński (morgwai) wrote :

Could we have this bug fixed, please? ;)
It confuses a lot of people, especially those not experienced: just type 'password change keyring ubuntu' into google and see how many howtos and bb posts about this are there.

Cheers

  Morg

Changed in shadow (Ubuntu):
status: New → Confirmed
Revision history for this message
David (edeca) wrote :

If this is only a wishlist item, how should a 9.04 user change their keyring password?

"System -> Preferences -> Encryption and Keyrings" does not seem to have an option for the keyring password. I only have tabs for "Encryption" and "PGP Passphrases". As per the first comment, I do have the seahorse package installed.

If it were obvious that the initial keyring password is linked to the chosen install password, this would be fine. However, it breaks (without obvious reason) for any of the following cases, which aren't exactly borderline:

- default installs where the users needs to change their password when the laptop is handed over
- people who change their passwords regularly

Perhaps someone who knows where the "Keyring" tab has gone can post here, so that future viewers of the bug know how to change their keyring password.

Revision history for this message
Piotr Morgwai Kotarbiński (morgwai) wrote :

It is pretty well hidden now: you have to go to "Accessories -> Passwords and Encryption Keys" then select "passwords tab", right click on the "Passwords: login" folder and choose "Change Password" option. I spent an hour to find it ;]

Cheers

  Morg

Revision history for this message
wallydallas (jrowe) wrote :

bug:
When I changed my Ubuntu logon password my automatic WiFi logon breaks.

expected:
If I change my Ubutu Logon password, the next time I boot my WiFi should logon to my AP automatically, using the cached WiFi password from previous days.

After I found this bug I waited a fewy days, did the google, and found some not so good advice. I tried to manually fix or workaround this using Apps-Accessories-Password and Encryption Keys. Nothing I could do would get my system to logon to WiFi automatically.

Workaround, create new user, move over all my documents, delete my original user account. FYI, there should be a better way to port Ubuntu User Documents from one computer to another. A dialog that says export/backup, with checkboxes to let the user select what sub-components to move/backup.

Revision history for this message
Kenrick Bingham (loxo) wrote :

On Ubuntu 10.04 (lucid):

The login keyring password seems to be changed together with the system 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.

Wouldn't this be more important than "wishlist"? This breaks things in a default install when the user first changes his/her password: he/she needs to continue to give the old password to unlock the keyring for nm-applet to get access to wlan keys/passphrases.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Bug attachments

Remote bug watches

Bug watches keep track of this bug in other bug trackers.