nm-applet loses right to access keyring after long hibernation and has no way to restore access

Bug #158017 reported by Markus Kienast on 2007-10-28
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Network Manager Applet
network-manager-applet (Ubuntu)

Bug Description

After a long hibernation cycle (one night) nm-applet is not granted access to the proper gnome-keyring anymore. By itself it is not wise enough to try to unlock the keyring again, ergo ask for the passphrase again. This does not happen when I hibernate only for a short time (5 minutes).

Specifying the WEP/WPA passphrase by hand does not work either, because nm-applet tries to save the phrase before it attempts to connect to the network. Failure in saving automatically results in failure to connect. This is a misconception as well I think! If I know the passphrase I should be able to connect, no matter what!

However, I can solve the problem with killing and restarting nm-applet. It then asks for the passphrase again. (I restarted the keyring-daemon as well, don't know if that was really necessary).

I also have this problem on a ThinkPad T40 with Gutsy and an Intel Pro Wireless 2100B card.

Pedro Villavicencio (pedro) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. The issue that you reported is one that should be reproducible with the live environment of the Desktop CD of the development release - Hardy Heron. It would help us greatly if you could test with it so we can work on getting it fixed in the next release of Ubuntu. You can find out more about the development release at http://www.ubuntu.com/testing/ . Thanks again and we appreciate your help.

Changed in network-manager-applet:
status: New → Incomplete
Pedro Villavicencio (pedro) wrote :

We are closing this bug report because it lacks the information we need to investigate the problem, as described in the previous comments. Please reopen it if you can give us the missing information, and don't hesitate to submit bug reports in the future. To reopen the bug report you can click on the current status, under the Status column, and change the Status back to "New". Thanks again!.

Changed in network-manager-applet:
status: Incomplete → Invalid
wvengen (wvengen) wrote :

fyi: I had this problem on Gutsy, but since I upgraded to Hardy it hasn't appeared anymore.

hackel (hackel) wrote :

I am experiencing this on Hardy as well. After resuming from hibernate, especially if I've connected to another network in the meantime, I enter my login password once to unlock the screen, then nm-applet asks for it again in order to unlock the keyring and supply my WPA key. I do not believe this is a dupe of 157511, since that is referring to the WPA key, NOT the login password. They are different issues.

Changed in network-manager-applet:
status: Invalid → Confirmed
Alexander Sack (asac) wrote :

could you check intrepid/jaunty and report whether this issue is still valid in NM 0.7?

Changed in network-manager-applet:
status: Confirmed → Incomplete
Alexander Sack (asac) wrote :

I think the original issue seems to be fixed. If you still see a similar issue check i nsyslog whether the connect fails. If thats the case NM re-asks for a password as it assumes that it might be wrong - especially when using wep encryption NM cannot tell whether password is wrong or you just got a driver/network timeout.

Changed in network-manager-applet:
status: Incomplete → Invalid
Sam Freilich (l33tminion) wrote :

#7: You're misreading the bug report. The problem isn't that the network fails to connect and asks for the _network_ password. It asks for the user's _login_ password to use gnome-keyring's default keyring to _look up_ the network password before trying to connect. That bug, which is the bug originally reported above, still exists in Karmic.

See bug #34898. gdm uses a pam module to unlock the default gnome-keyring keyring on login. gnome-screensaver should do the same thing when the user enters their password to unlock the screen. That would solve this bug.

Changed in network-manager-applet (Ubuntu):
status: Invalid → New
Sam Freilich (l33tminion) wrote :

Both /etc/pam.d/gdm and /etc/pam.d/gnome-screensaver contain:
auth optional pam_gnome_keyring.so

However, only the former contains:
session optional pam_gnome_keyring.so auto_start

That's how it should be according to the documentation:

Is gnome-keyring-daemon supposed to be killed on hibernate? If that's the case, then it should be sufficient to append auto_start to the end of the auth line in /etc/pam.d/gnome-screensaver, since that pam module checks if the keyring daemon is already running and doesn't start it again if it is.

Sam Freilich (l33tminion) wrote :

Seems possibly related to bug #150432, though neither of the reasons the commenters there stated for gnome-keyring-daemon dying on hibernate seem to be true for me.

Sam Freilich (l33tminion) wrote :

After a little investigation, it seems gnome-keyring-d _isn't_ dying on hibernate, at least not always. So either it's dying sporadically for some reason, or there's some other reason why that line in gnome-screensaver's PAM config (which should unlock the default keyring) doesn't prevent network-manager from thinking the keyring is still locked.

Thank you for your bug report. This bug has been reported to the developers of the software. You can track it and make comments at: https://bugzilla.gnome.org/show_bug.cgi?id=603626

Changed in network-manager-applet (Ubuntu):
importance: Undecided → Medium
status: New → Confirmed
Changed in network-manager-applet:
importance: Unknown → Medium
status: Unknown → New

Thank you for taking the time to report this bug and helping to make Ubuntu better. We are sorry that we do not always have the capacity to look at all reported bugs in a timely manner.
There have been many changes in Ubuntu since the last comment and your problem may have been fixed with some of the updates. It would help us a lot if you could test the current Ubuntu version (10.10). If you can test it, and it is still an issue, we would appreciate if you could upload updated logs by running apport-collect <bug #>, and any other logs that are relevant for this particular issue.

Changed in network-manager-applet (Ubuntu):
status: Confirmed → Incomplete
Matt Fischer (mfisch) on 2011-11-24
summary: - nm-applet looses right to access keyring after long hibernation and has
+ nm-applet loses right to access keyring after long hibernation and has
no way to restore access
Thomas Hood (jdthood) on 2012-08-08
tags: added: karmic
Thomas Hood (jdthood) wrote :

Has anyone had this problem recently?

Changed in network-manager-applet:
status: New → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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