Cannot access wireless networks keys when user change his session password.
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
| GNOME Keyring |
Unknown
|
Wishlist
|
||
| gnome-keyring (Ubuntu) |
Medium
|
Unassigned | ||
| shadow (Ubuntu) |
Wishlist
|
Unassigned | ||
Bug Description
Binary package hint: gnome-keyring-
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.
description: | updated |
Yan Li (yanli) wrote : | #1 |
Changed in gnome-keyring-manager: | |
status: | New → Confirmed |
importance: | Undecided → Medium |
Chad (zzglitch) wrote : | #2 |
This bug us quite annoying and is generating some bad workaround advice on other forums.
Saivann Carignan (oxmosys) wrote : | #3 |
Linked upstream bug http://
You can help that bug to get fixed by contributing to that bug report.
Changed in gnome-keyring-manager: | |
status: | Confirmed → Triaged |
Changed in gnome-keyring: | |
status: | Unknown → New |
Saivann Carignan (oxmosys) wrote : | #4 |
According to Gnome developpers, it doesn't work only because libpam-
Changed in gnome-keyring: | |
status: | New → Invalid |
Sebastien Bacher (seb128) wrote : | #5 |
That's not a gnome-keyring issue, passwd should be changed to use the pam module which is a known request and being discussed
Changed in gnome-keyring: | |
status: | Triaged → Invalid |
Saivann Carignan (oxmosys) wrote : | #6 |
According to Sebastien Bacher comment, I set pam Status to confirmed and Importance to Wishlist.
Changed in pam: | |
importance: | Undecided → Wishlist |
status: | New → Confirmed |
Nate R (nate-ridderman) wrote : | #7 |
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) wrote : | #8 |
The missing configuration item, as per http://
In /etc/pam.d/passwd, add a line like this to the 'password' block:
password optional pam_gnome_
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.
Mat Tomaszewski (mat.t.) wrote : | #10 |
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.
Changed in hundredpapercuts: | |
importance: | Undecided → Medium |
status: | New → Confirmed |
sam tygier (samtygier) wrote : | #11 |
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) wrote : | #12 |
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.
Changed in hundredpapercuts: | |
status: | Confirmed → Invalid |
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) wrote : | #14 |
kamugisha bonaventure : Please ask questions in http://
Steve Langasek (vorlon) wrote : | #15 |
This was never a bug in shadow. Closing that task as invalid.
Changed in shadow (Ubuntu): | |
status: | Confirmed → Invalid |
Steve Langasek (vorlon) wrote : | #16 |
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-
Build-
* 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-
* Standards version is 3.8.1.
* 03_secure-
assertion error in the secure memory allocator. Closes: #522266.
* pam-configs/
stanzas.
* libpam-
* libpam-
* Depend on libpam-runtime (>= 1.0.1-6).
* libpam-
passwd module.
Changed in gnome-keyring (Ubuntu): | |
status: | Invalid → Fix Released |
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.
Changed in hundredpapercuts: | |
status: | Invalid → Fix Committed |
milestone: | none → round-2 |
Saivann Carignan (oxmosys) wrote : | #18 |
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.
Changed in gnome-keyring (Ubuntu): | |
status: | Fix Released → New |
Sebastien Bacher (seb128) wrote : | #19 |
there is no merge the karmic version is a direct sync on debian
Michael Rooney (mrooney) wrote : | #20 |
The gnome-keyring task is back to New so I think that means the hundredpapercuts task isn't Fix Committed anymore, alas.
Changed in hundredpapercuts: | |
status: | Fix Committed → Confirmed |
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.
Changed in hundredpapercuts: | |
milestone: | round-2 → round-10 |
david (davidelizondo2006) wrote : | #22 |
error xorg bug !!! grave error !!!
Changed in gnome-keyring (Ubuntu): | |
status: | New → Fix Released |
david (davidelizondo2006) wrote : | #23 |
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=
Build Date: 28 September 2009 10:13:57AM
xorg-server 2:1.6.3-1ubuntu7 (<email address hidden>)
Before reporting problems, check http://
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/
(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/
Entry deleted from font path.
(==) FontPath set to:
/usr/share/
Changed in gnome-keyring (Ubuntu): | |
status: | Fix Released → New |
deew (dee-wykoff) wrote : | #24 |
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.
Changed in hundredpapercuts: | |
status: | Confirmed → Invalid |
milestone: | round-10 → none |
Changed in gnome-keyring (Ubuntu): | |
status: | New → Confirmed |
komputes (komputes) wrote : | #26 |
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) wrote : | #27 |
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_
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:/
komputes (komputes) wrote : | #28 |
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) wrote : | #29 |
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-
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) wrote : | #30 |
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) wrote : | #31 |
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.
Changed in gnome-keyring (Ubuntu): | |
status: | Confirmed → Triaged |
Changed in gnome-keyring: | |
importance: | Unknown → Wishlist |
status: | Invalid → Unknown |
Changed in gnome-keyring (Ubuntu): | |
status: | Triaged → Fix Released |
no longer affects: | hundredpapercuts |
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.