Cannot access wireless networks keys when user change his session password.

[Saivann Carignan]

Binary package hint: gnome-keyring-manager

When a user change his session password inside Ubuntu Gutsy, the "default" keyring password isn't updated so all keys and password that are on this keyring become unavailable without the old user password, including keys for wireless networks.

That means that laptop users won't be able to connect to their wireless networks if they change their session password because they'll have to remove the "default" keyring and create another with the good password, and type again ALL wireless network keys in order to get connected to their protected wireless networks. Or else the user can type is old password each time he wants to connect on a wireless networks, but that's very bad because lamda users won't know what to do when gnome-keyring will ask them for a password they don't know.

A fix for this bug should be to update users-admin tool to also change the password for the default keyring when the user change his session password. This fix would probably not work is the user changes his password with another tool than users-admin

Another fix would be to find a way to make gnome-keyring use current user password for the special "default" keyring and not in his own keyring passwords. I think that this fix should work under every circumstances if that fix is possible.

Steps to reproduce that bug are :

1. Take a laptop that can connect to WEP/WPA wifi networks with a clean Linux Ubuntu Gutsy install on it
2. Connect to a WEP or WPA protected network and type the key to access the network
3. The key for the network is saved in the "default" keyring and Ubuntu won't ask you again to access this network
4. Change you user password in System / Administration / Users and Groups
5. Reboot your computer and login again, ubuntu should now ask you for a password to unlock the "default" keyring which still uses your old session password.

[Yan Li (yanli)]

Yes. It's really strange to me that the default keyring password doesn't follow user's password when changed. IMHO, if a program choose to use user's password, it should follow user's password.

Today it took me half-and-hour to realize that I should use my _initial_ old password to access my keyring.

Or if it couldn't follow user's password, there should be a way to change it to any password I wish on demand.

Thanks.

[Chad (zzglitch)]

This bug us quite annoying and is generating some bad workaround advice on other forums.

[Saivann Carignan (oxmosys)]

Linked upstream bug http://bugzilla.gnome.org/show_bug.cgi?id=505362

You can help that bug to get fixed by contributing to that bug report.

[Saivann Carignan (oxmosys)]

According to Gnome developpers, it doesn't work only because libpam-gnome-keyring is not correctly configured. We should follow that procedure to enable pam to always update password for the login keyring to be always the sane as the user password.

http://live.gnome.org/GnomeKeyring/Pam

[Sebastien Bacher (seb128)]

That's not a gnome-keyring issue, passwd should be changed to use the pam module which is a known request and being discussed

[Saivann Carignan (oxmosys)]

According to Sebastien Bacher comment, I set pam Status to confirmed and Importance to Wishlist.

[Nate R (nate-ridderman)]

I ran into this bug on Intrepid. It seems like a fairly common problem, and it's not intuitive to work around it for several reasons:

1. Most users don't know what a keyring is, or that Ubuntu stores their WEP key using the keyring.
2. Even for users who understand this, they would not realize that their login password was being used to access the keyring because it just works - until you change your password.

For me, the problem was particularly bad because I changed my password months before I installed a wireless card. I was upgrading a desktop that I moved to a room far away from my router. If I already had a wireless card installed and then I changed my password, I would perhaps notice the correlation. In my case, I never thought that the bug would be related to something I did months ago. Luckily the forums provided insight. The problem with fixing network bugs is that you need an internet-accessible computer to search the forums and bug reports.

This bug also crashed my network manager applet, as far as I can tell. I had no nm-applet in the taskbar, but the process was running. When I re-synced the keyring and login passwords and restarted my computer, the nm-applet reappeared in the taskbar and the wireless connection loaded by default.

Long story short, it seems like an important bug to fix that would make Ubuntu more accessible to everyday folks.

[DChill (dchill42)]

The missing configuration item, as per http://live.gnome.org/GnomeKeyring/Pam, seems to be as follows:

In /etc/pam.d/passwd, add a line like this to the 'password' block:
    password optional pam_gnome_keyring.so

Once I added this line, the problem was resolved on both my Intrepid x64, and my son's Intrepid 386. It appears that simply making this line a standard part of the default Ubuntu installation would fix the issue. All other directives on the Pam page were consistent with my default installation.

[David Siegel (djsiegel-deactivatedaccount)]

In Jaunty, after changing my user password, this dialog greets me on login without fail. The dialog is modal, so I cannot interact with my computer until I have attended to this dialog. A "remember my password" setting would be really helpful for users who do not wish to unlock their keyring each time they log in.

[Mat Tomaszewski (mat.t.)]

There are couple of other issues, other than the very fact of modal dialog appearing:

- lot of scary technical jargon within the dialog,
- English used isn't very good.

[sam tygier (samtygier)]

it would be nice if this could be solved in a way that also works for people who set gdm to log in automatically. and also for when you connect to an encrypted network from a the live cd (you are currently asked to create a keyring password).

[Rick Spencer (rick-rickspencer3)]

This is an important bug to be fixed, but is quite involved to fix and the proper solution is not clear. Setting to "Invalid" in the paper cuts project.

[kamugisha bonaventure (kamugishabo)]

 I have installed ubuntu but i am dont know how to connect to the local area network .by using proxy i m mean at universty only by specifying cess point. so how to proceed?

[Saivann Carignan (oxmosys)]

kamugisha bonaventure : Please ask questions in http://ubuntuforums.org/ or http://answers.launchpad.net/ . Bug reports are used to work on fixing bugs, not to provide support to users.

[Steve Langasek (vorlon)]

This was never a bug in shadow. Closing that task as invalid.

[Steve Langasek (vorlon)]

The actual fix was included in Debian version 2.26.0-3 of gnome-keyring, and that fix is now in karmic. Changelog:

gnome-keyring (2.26.0-3) unstable; urgency=low

  * libgp11-0.shlibs: add shlibs file for libgp11. Closes: #522381.
  * libgcr0.symbols, libgnome-keyring0.symbols: add
    Build-Depends-Package fields.
  * libgp11-0.symbols: also add symbols file for libgp11.
  * Add missing build-dep on intltool.
  * Pass /etc/ssl/certs as the directory for root certificates.
  * Update glib dependency for libgnome-keyring-dev.
  * Standards version is 3.8.1.
  * 03_secure-mem_crash.patch: new patch, stolen upstream. Fixes
    assertion error in the secure memory allocator. Closes: #522266.
  * pam-configs/gnome-keyring: ship a PAM configuration for the Password
    stanzas.
  * libpam-gnome-keyring.install: install it.
  * libpam-gnome-keyring.{postinst,prerm}: run pam-auth-update.
  * Depend on libpam-runtime (>= 1.0.1-6).
  * libpam-gnome-keyring.README.Debian: remove the documentation for the
    passwd module.

[David Siegel (djsiegel-deactivatedaccount)]

This was originally a confirmed paper cut, and although it appeared to be too difficult to fix as part of the paper cuts project and was marked invalid, it was fixed anyway so I'd like to re-identify it as a paper cut.

[Saivann Carignan (oxmosys)]

Steve Langasek : I can still reproduce that issue on karmic with gnome-keyring 2.26.1-1 . Are you sure that ubuntu didn't drop pam support in the merge? If this is not the case, then something else probably needs to be enabled in order to fix that bug. login keyring keeps old password when changing password for a new one, and keep asking for the old password on next login.

[Sebastien Bacher (seb128)]

there is no merge the karmic version is a direct sync on debian

[Michael Rooney (mrooney)]

The gnome-keyring task is back to New so I think that means the hundredpapercuts task isn't Fix Committed anymore, alas.

[David Siegel (djsiegel-deactivatedaccount)]

Rescheduling this paper cut, as its Fix Committed status was reverted to Confirmed. This may not be a paper cut after all; if someone can determine that it is not a paper cut, please mark Invalid.

[david (davidelizondo2006)]

 error xorg bug !!! grave error !!!

[david (davidelizondo2006)]

X.Org X Server 1.6.3
Release Date: 2009-7-31
X Protocol Version 11, Revision 0
Build Operating System: Linux 2.6.24-23-server i686 Ubuntu
Current Operating System: Linux david-desktop 2.6.31-11-generic #38-Ubuntu SMP Fri Oct 2 11:55:55 UTC 2009 i686
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-2.6.31-11-generic root=UUID=490a04e5-6e1e-457a-a95c-bb88ee3dadf2 ro quiet splash
Build Date: 28 September 2009 10:13:57AM
xorg-server 2:1.6.3-1ubuntu7 (<email address hidden>)
 Before reporting problems, check http://wiki.x.org
 to make sure that you have the latest version.
Markers: (--) probed, (**) from config file, (==) default setting,
 (++) from command line, (!!) notice, (II) informational,
 (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: "/var/log/Xorg.0.log", Time: Fri Oct 2 15:55:15 2009
(II) Loader magic: 0x1fbc0
(II) Module ABI versions:
 X.Org ANSI C Emulation: 0.4
 X.Org Video Driver: 5.0
 X.Org XInput driver : 4.0
 X.Org Server Extension : 2.0
(II) Loader running on linux
(--) using VT number 7

(--) PCI:*(0:0:2:0) 80ee:beef:0000:0000 InnoTek Systemberatung GmbH VirtualBox Graphics Adapter rev 0, Mem @ 0xe0000000/16777216
(==) Using default built-in configuration (30 lines)
(==) --- Start of built-in configuration ---
 Section "Device"
  Identifier "Builtin Default vboxvideo Device 0"
  Driver "vboxvideo"
 EndSection
 Section "Screen"
  Identifier "Builtin Default vboxvideo Screen 0"
  Device "Builtin Default vboxvideo Device 0"
 EndSection
 Section "Device"
  Identifier "Builtin Default vesa Device 0"
  Driver "vesa"
 EndSection
 Section "Screen"
  Identifier "Builtin Default vesa Screen 0"
  Device "Builtin Default vesa Device 0"
 EndSection
 Section "Device"
  Identifier "Builtin Default fbdev Device 0"
  Driver "fbdev"
 EndSection
 Section "Screen"
  Identifier "Builtin Default fbdev Screen 0"
  Device "Builtin Default fbdev Device 0"
 EndSection
 Section "ServerLayout"
  Identifier "Builtin Default Layout"
  Screen "Builtin Default vboxvideo Screen 0"
  Screen "Builtin Default vesa Screen 0"
  Screen "Builtin Default fbdev Screen 0"
 EndSection
(==) --- End of built-in configuration ---
(==) ServerLayout "Builtin Default Layout"
(**) |-->Screen "Builtin Default vboxvideo Screen 0" (0)
(**) | |-->Monitor "<default monitor>"
(**) | |-->Device "Builtin Default vboxvideo Device 0"
(==) No monitor specified for screen "Builtin Default vboxvideo Screen 0".
 Using a default monitor configuration.
(**) |-->Screen "Builtin Default vesa Screen 0" (1)
(**) | |-->Monitor "<default monitor>"
(**) | |-->Device "Builtin Default vesa Device 0"
(==) No monitor specified for screen "Builtin Default vesa Screen 0".
 Using a default monitor configuration.
(**) |-->Screen "Builtin Default fbdev Screen 0" (2)
(**) | |-->Monitor "<default monitor>"
(**) | |-->Device "Builtin Default fbdev Device 0"
(==) No monitor specified for screen "Builtin Default fbdev Screen 0".
 Using a default monitor configuration.
(==) Automatically adding devices
(==) Automatically enabling devices
(WW) The directory "/usr/share/fonts/X11/cyrillic" does not exist.
 Entry deleted from font path.
(==) FontPath set to:
 /usr/share/fonts/X...

[deew (dee-wykoff)]

I have this issue on a netbook running karmic. As a few others may have pointed out, this should not depend on the password being typed in at login. Some of use use auto-login for young children that have trouble with passwords.

[David Siegel (djsiegel-deactivatedaccount)]

This issue is not trivial, and cannot be considered a paper cut.

[komputes (komputes)]

I can confirm this is still happening on gnome-keyring 2.28.1 (Karmic).

David, when you say that this is not trivial, can you objectively explain what needs to be done and why we cannot accomplish it. I may be incorrect, but from what I understand, shouldn't it be a case of:

-Unlocking the keyring
-Taking the passwords and rewrapping them with a new keyring password (perhaps in a new keyring?)

Currently, changing a user password does not automatically prompt for the keyring password. Is it technically possible to *manually* change a keyring password? If so, how would one accomplish this task?

[Milan Bouchet-Valat (nalimilan)]

This is not trivial because nobody has found out where's the real problem. A paper cut must have a clear and simple solution.

AFAIK, our /etc/pam.d/passwd file is right as it includes the line
password optional pam_gnome_keyring.so

So the problem is elsewhere. Please note that you should not use the "default" keyring, contrary to what is told in the bug description: only the "login" keyring is unlocked on login. Also, you must not have changed your password using users-admin in versions older than the final Karmic one. Else that won't work. Can you confirm that's the case on your systems?

And yes, you can change your keyring password manually: see https://bugzilla.gnome.org/show_bug.cgi?id=338088#c30

[komputes (komputes)]

I'm sorry, I did not know that I had set up two keyrings (login + default). I was under the impression that I had only created one keyring (default) when connecting to a wireless access point for the first time.

Milan, The only thing I can confirm is that this is very broken. I have changed my password through "users-admin" and "gnome-about-me --password" but both of them refuse to change my password (Spining wheel thing never end). passwd from my user also cannot make the change (perhaps because they are similar).

You can test this yourself, please share your results. Try changing a user password from:
910??)ubuntu(!!910
to
910??)ubuntu(!!904

Please let me know if you are able to make this change?

The only way I can change my password is by using:
sudo passwd komputes

Since I use passwd (CLI, not a GNOME utility) I assume the (default?) keyring password does not change.

[Milan Bouchet-Valat (nalimilan)]

If you can't change your password using gnome-about-me, then that's a bug in that program. On my box, this is working fine. No need to comment on other more or less related reports. Please report a new bug against the package gnome-control-center for that.

The "default" keyring will never have it's password changed automatically, only "login" is designed for that. The command "sudo passwd" should work with the GNOME keyring as it's the standard way of doing it, and that's what is used anyway in the background. users-admin is merely running gnome-about-me currently, so that's the same problem.

Does anybody else experience problems? Else we should close this bug.

[Milan Bouchet-Valat (nalimilan)]

Err, correction: the command "passwd" will update your keyring. "sudo passwd" can't do this because it does not ask for the old password. That's a known issue, but this behavior is required for admins to change user passwords by themselves.

[Saivann Carignan (oxmosys)]

I can still confirm this bug in lucid alpha 3.

I don't know what can be the reason why the keyring password is not updated, but it is not.
I only have to change user password with users-admin, gnome-about-me or passwd (any of these have the bug, I tested them one by one) and at next login, ubuntu asks me the password to unlock the keyring when trying to connect to the wireless network. The login keyring password is still my old user password.

Therefore while this issue *should* be fixed, unfortunately it is not, yet. Something else that is missing needs to be done to fix this.