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

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.

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

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.

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

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

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

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.

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.

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.

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.

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).

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.

 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?

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.

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

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.

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.

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.

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

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

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.

 error xorg bug !!! grave error !!!

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...

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.

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

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?

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

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.

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.

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.

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.