nm-applet: requests keyring password, doesn't use it

Bug #125075 reported by Alex Mauer
30
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-keyring (Ubuntu)
Invalid
Low
Unassigned
network-manager-applet (Ubuntu)
Fix Released
Low
Unassigned

Bug Description

On login, nm-applet asks to open the gnome keyring, prompting for a password. I deny it, since I don't have that password stored in my keyring.

Then it prompts for my WPA password. I enter it.

At that point it will *sometimes* request the keyring password again.

It should only ask for the keyring password once, and ideally it should not ask at all since the WPA password isn't stored there.

Revision history for this message
Basilio Kublik (sourcercito) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Please answer these questions:

* Is this reproducible?
* If so, what specific steps should we take to recreate this bug?

This will help us to find and resolve the problem.

Revision history for this message
Alex Mauer (hawke) wrote :

I can reproduce it, yes. It happens every day.

The steps I take: select a WPA-protected wireless network from nm-applet. it will, in order:
1. bring up the gnome-keyring password dialog. Here I hit "deny"
2. prompt for the network information. Here I enter the WPA key. At this point the applet sits for awhile while the network connection is negotiated.
3. bring up the gnome-keyring password dialog. Again, I hit "deny". At this point the applet switches from the negotiation animation to the wireless status bars. Previously it didn't always ask for the password a second time, but as far as I can tell it now does so consistently.

I would prefer that it never asked for the keyring password at all, as I don't store the WPA key there. It especially should also not ask a second time, unless there's an option in the dialog from step 2 to store the passphrase in the keyring. (that is, assuming that it's prompting in order to store the key -- I have no way of telling why it's trying to open the keyring; for all I can tell it's trying to open it in order to send all my passwords to a random email address)

Revision history for this message
Basilio Kublik (sourcercito) wrote :

i cannot reproduce your bug following this procedure.

here, when i click on a WPA-PSK protected network, ask for password (this time network-manager), i fill the info, and join the network, then a gnome-keyring dialog pops up and ask me for the keyring password, here if i deny the access, the connection is immediately dropped, but if instead press the Esc key, the gnome-keyring dialog disappears and doesn't shows again .

perhaps is something in your user's configuration that calls to gnome-keyring before you try to establish the network connection.

could you please try to reproduce this with a newly created user.

Revision history for this message
Basilio Kublik (sourcercito) wrote :

i forgot to say that i'm using:

gnome-keyring 2.19.90-0ubuntu1
network-manager 0.6.5-0ubuntu9
network-manager-gnome 0.6.5-0ubuntu8

in a gutsy installation

Revision history for this message
Alex Mauer (hawke) wrote :

I cannot reproduce with a newly-created user.
One interesting tidbit (with my main user):
Using gnome-keyring-manager, I looked at the default keyring. Two entries, including the WPA passphrase in question, were visible in the list without being prompted. The names of the other keys (VPN passwords) each required individual prompts just in order to view the name.

I removed the WPA passphrase entry. Then I reconnected to the wireless network. This time I was not prompted to open the keyring (either before or after entering the wpa passphrase.) After I entered the passphrase, the network connected, and I was not prompted to open the keyring to store the passphrase, but the passphrase showed up in keyring manager. Further reconnections did not prompt for the passphrase at all.

Upon logging out and back in, nm-applet was back to previous (initially reported) behaviour.
I opened gnome-keyring-manager (opening the default keyring) and reconnected. nm-applet no longer asked for access to the keyring, and connected automatically.

I also did an experiment:
Using gnome-keyring-manager, I removed 'read' access to the WPA passphrase for nm-applet. Then I reconnected to the wireless network. I was prompted to allow access to the passphrase. I selected "allow once" and nm-applet connected without prompting for the passphrase. Read access to the passphrase was also restored. I removed read access again, and reconnected, this time denying access to the passphrase. nm-applet prompted for the WPA passphrase, and then for some reason the read access to that passphrase was restored again (without prompting)

Then I removed read and write access to the passphrase for nm-applet, and reconnected to the network. I was prompted to allow access to the passphrase, and selected "allow once". nm-applet connected, and I was prompted to allow access again, and again selected "allow once". read and write access were restored. I removed read/write again, and reconnected, this time denying access. I was prompted for the WPA passphrase, and then prompted to allow access to the key for nm-applet. I again denied it. This time, nm-applet created an extra key in the keyring containing the wpa passphrase.

Is there something the keyring does not understand about the word "deny"?

Revision history for this message
Alex Mauer (hawke) wrote :

Ah, I was able to reproduce the problem with the new user:

After initial login and connection to the network (creating a new default keyring, storing the wpa passphrase in that keyring), log out and back in. Reconnect to the network, and deny access to the keyring. nm-applet prompts for the wpa passphrase, and then it tries to access the keyring again. (This is the initially-reported problem)

Alex Mauer (hawke)
Changed in gnome-keyring:
status: Incomplete → New
Revision history for this message
Pedro Villavicencio (pedro) wrote :

Are you still getting the issue with latest updates?

Revision history for this message
Andrew Frank (frank-geoinfo) wrote :

i get the problem again -
it is a bug, because when i am asked for the password first, i ticked: automatically open this keyring whenever i login,
nevertheless i am asked for the password (to open a wap connection)
and i am asked twice.

i have a completely updated gutsy installation.

Revision history for this message
Alex Mauer (hawke) wrote :

I still get this problem, yes.

Revision history for this message
Andy (andy-morgan) wrote :

HiJ

Just to say, the same thing happens to me. Not that I'm as adventurous with my experiments, sorry I couldn't follow all that "allow once, turn round three times and spit" thing, but I'm sure it's the same issue. Crazy thing connects to the wireless when I click deny! Bizzare, almost human in nature.

Thanks for all the trouble you are taking to get this fixed if there is anything I can do to help just ask.

Cheers

Andy

Revision history for this message
Alexandre Campo (alexandre-campo) wrote :

Same problem here. I login, then nm-applet asks pwd for keyring... problem discussed in many places, several workaround proposed. This includes :
http://ubuntuforums.org/showthread.php?t=187874
http://ubuntuforums.org/showthread.php?p=2776815#post2776815

I'll try the second one. I am not convinced that it is secured. Any hint ?
What is the progress ?

Revision history for this message
Alexandre Campo (alexandre-campo) wrote :

The workaround of the second link did not work in my Gutsy. At login screen I had a popup saying auth failed, this pop would keep opening all the time on the top of the login, preventing me to actually enter the password and login. Had to use a recovery boot and remove mods.

Revision history for this message
Tim Fuchs (tim-fuchs) wrote :

My keyring manager also behaves very weird/annoying, similar but still slightly different to the description of the OP.

That's what happens when I start my computer:

1. A dialog pops up and asks for my keyring password which stores my WPA key. When I enter the password and press ok the same dialog pops up again. I can do this as often as I want.

2. I press deny to get rid of that useless dialog.

3. A dialog pops up that looks just like the first one except it has a little check box under the password entry which says something like "Remember the password". While the checkbox doesn't seem to have any effect whatsoever this dialog actually accepts my keyring password and a connection to my wireless is established

4. A dialog pops up asking for my password again, it behaves just like the first one, i.e. it pops up again and again when I enter my password so I just click deny and I'm fine.

It's also interesting what happens when I lose my wlan connection (which happens randomly every few hours, but that's an other story):

1. I choose my wlan network from the list.
2. A dialog pops up asking me for my keyring password. When I enter my password and press OK the dialog just ops up again. When I don't enter the password and click DENY network-manager connects to my wlan. Security-wise, this behaviour is.. errr... interesting.

Even more annoying is the behaviour when I connect to a WebDAV share with nautilus:

1. I choose Places -> Connect to server and enter the WebDAV details
2. I click on the new icon named after the connection on my desktop
3. Around ten dialogs pop up asking me for the password.
4. Whenever I do sth. in the nautilus window of the WebDAV connection, i.e. create a file, open a folder... 10 new dialogs pop up asking me for my password. It doesn't matter which of the options in the dialog (Forget password immediately, Save password for this session, Save password forever) I choose.

So to sum it up: Using anything that accesses a keyring ib Ubuntu Gutsy is either annyoing or practically unusable, Any suggestions?

Revision history for this message
Africanus (africanus) wrote :

I have the same behaviour on three gutsy installations on different hardware and one hardy, so much so that NetworkManager is unusable. I use the interfaces file or Wicd if I want to roam. It would be a sad day to see Hardy released like this.

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

seems to be a network-manager issue

Revision history for this message
Basilio Kublik (sourcercito) wrote :

Hi there
do you still experience this issue with the current version of the application?, could you please try to reproduce this using the live environment of the Desktop CD of the development release - Hardy Heron.

Thanks in advance

Changed in network-manager:
assignee: nobody → sourcercito
importance: Undecided → Low
status: New → Incomplete
Revision history for this message
Alex Mauer (hawke) wrote :

I don't know about the desktop CD's live environment, but I do still have the same problem in an up-to-date hardy installation, freshly installed less than a month ago from hardy alpha 5.

Revision history for this message
Basilio Kublik (sourcercito) wrote :

Hi Alex
are you able to reproduce this with a new user account?, i haven't seen this for some time now.

Revision history for this message
Alex Mauer (hawke) wrote :

I just tested with the daily live CD (version 2008-03-19).

I was able to duplicate the problem.

Steps to duplicate:
1. boot from livecd
2. connect to a WPA-protected network. At this point, the system will prompt for a new password for the default keyring. Enter one. Now the keyring exists but is unlocked.
3. Log out. The default keyring is locked.
4. Log in.
5. Connect or reconnect to a WPA-protected network. The system will prompt for a password to open the default keyring. Click "deny"
6. Enter the WPA passphrase.
7. The system will prompt for a password to open the default keyring again.

Revision history for this message
Richard Bevan (rjbevan53) wrote :

I only started having a problem when I updated my user password. To gain access to my wireless network, I had to type in my old password. I have now gone back to my original password when I got my PC and it now works OK without asking for my user password. So it would appear that the applet is storing a password when the system is built (as I updated to Gutsy Gibbon with the original password) but it doesn't get updated when there is a password change.

Revision history for this message
Alex Mauer (hawke) wrote :

Richard: I expect your problem is due to 'libpam-gnome-keyring' and unrelated to this one. Basically, libpam-gnome-keyring just uses your system password to automatically unlock the gnome keyring on login, but apparently doesn't update the keyring password when you change the system one. I believe you can use 'seahorse' to change the password on the keyring, and if you change it to match your login one that will begin working automatically for you again.

Revision history for this message
Richard Bevan (rjbevan53) wrote :

Alex: Thanks for your prompt reply. I am new to Linux having recently bought a Dell machine with Ubuntu pre-loaded. So I am still learning. I had a look on the web for Seahorse and I have loaded the application but can't see how you run it or what you need to do to change my password. Any help appreciated.

Richard

Revision history for this message
Alex Mauer (hawke) wrote :

if you installed seahorse from the Ubuntu package, it should appear in System -> Preferences -> Encryption and Keyrings. In there, there should be a tab "Password Keyrings", with a button for "Change Unlock Password".

Revision history for this message
Richard Bevan (rjbevan53) wrote :

Alex: Found it. In my version the tab is called "GNOME Keyring" that allows you to change the master password. So also changed my user password to be the same. So after re-booting only requires my user password. Thanks.

Revision history for this message
eschenberger (emil9999) wrote :

my observations as a computer administrator are the following: in my school sometimes apple computers ask users for keyring or keychain passwords. i've never seen one who knows what that is. users try to click these boxes away or ignore them.

at private homes people are happy when they found out 1. the router boxes web interface ip-address 2. the routers password 3. the place where to enter their internet providers login and password 4. finding the place where to enter a wlan password into the router box 5. and into the laptop 6. deciding hereby to use wep, wpa2 or whatever.

but when there's popping up a box asking for a keyring password most users are at a point where they are frustrated to a maximum. they don't know what to do.

"keyring" is a nice metapher but in my opinion no one needs them. within a normal user account there aren't that much passwords to bundle them into a keyring.

my advice is. keyrings shouldn't be installed and activated by default. keyrings are only a simplification for advanced users, knowing what it is. for most people they are an unnecessary annoying complification.

Changed in network-manager:
assignee: sourcercito → nobody
Revision history for this message
Tan Kah Ping (kahping) wrote :

I also get this behaviour i Hardy. I use WEP auth for my wireless.

on login, I get a dialog asking me for default keyring password so that nm-applet can access the WEP key stored in the keyring. After I typed in my password, it accepts and my wireless connects successfully and doesn't ask me for keyring password again until i reboot. I didn't try logout then re-login though

Revision history for this message
Nicolas Albert (nicoa380) wrote :

@Tan Kah Ping :
you should install the libpam-gnome-keyring package and log you again by gdm. It would ask you your gnome-keyring password and propose to remind the password.
Hardy is great :)

Revision history for this message
derfie (derfie) wrote :

In hardy I solved the problem according to this link:
http://ubuntuforums.org/showthread.php?t=776176

Revision history for this message
Tan Kah Ping (kahping) wrote :

@Nicholas:
Trying to install, I get the following:
libpam-gnome-keyring is already the newest version.
0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

It's installed by default I think, but there's no option to remember(remind?) the password.

@derfie:
The solution in that thread may work, but isn't setting no keyring password a security risk?

Revision history for this message
Michael Nagel (nailor) wrote :

i am still having a problem:

- i boot my pc
- login to gnome
- i am asked to unlock the keyring to get access to the wireless
- i enter the password and get connected
>>>- i am asked for my password once again <<<

is any further information required?

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

the issue is not a gnome-keyring one

Changed in gnome-keyring:
importance: Undecided → Low
status: New → Invalid
Revision history for this message
Sebastien Bacher (seb128) wrote :

the previous comment was not clear, the cancel action issue is fixed in intrepid, asking for a password when not required is an application issue

Revision history for this message
Alex Mauer (hawke) wrote :

As I understand it, prompting for a password is a gnome-keyring problem, because in order for the application to find out if it has a key stored in the keyring, the keyring must first be unlocked by entering the keyring passphrase. Is this not the case?

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

right, that's the whole gnome-keyring point, protect the informations you store there, would you consider it secure if any application could set a flag to not require credential to read informations? network-manager should note somewhere else if a password is stored in the gnome-keyring for a network and only do a query if that's the case

Revision history for this message
Alex Mauer (hawke) wrote :

Hmm, IMO the point of gnome-keyring is to protect the passwords/passphrases/encryption keys. I wouldn't suggest allowing an application to control whether the password is freely readable, no.

But the fact that network-manager has a password stored in gnome-keyring is not sensitive information. Only the password itself is. So network-manager should be able to query gnome-keyring to find out if there's a passphrase there. As it is now, network-manager queries for it, but in order to find out, gnome-keyring must ask the user to unlock the key. And once that's done, the keyring is readable, even though there's no reason for it to be unlocked at all. That is less secure, not more so.

Having network-manager store that information elsewhere is begging for sync problems. What happens if network-manager stores a key in the keyring, and then it's deleted from the keyring? Answer: we're back to where we are now, with network-manager causing gnome-keyring to prompt the user and still not having the information it needs to work. Or the other way round, what happens if the passphrase is stored, but network-manager loses the information that it's stored there? Answer: network-manager never tries to use gnome-keyring, so must ask the user for the key every time.

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

the gnome-keyring is made to store passwords and not random informations, if you want to discuss the design you should open a bug on bugzilla.gnome.org or contact the upstream mailing list, ubuntu will not do such changes in a distribution specific way

Revision history for this message
James Dupin (james.dupin) wrote :

excerpts from my user.log

sudo: Passphrase key already in keyring
sudo: Error attempting to add passphrase key to user session keyring; rc = [1]
sudo: There is already a key in the user session keyring for the given passphrase.
sudo: Passphrase key already in keyring
sudo: Error attempting to add passphrase key to user session keyring; rc = [1]
sudo: There is already a key in the user session keyring for the given passphrase.
sudo: Passphrase key already in keyring
sudo: Error attempting to add passphrase key to user session keyring; rc = [1]
sudo: There is already a key in the user session keyring for the given passphrase.
sudo: Passphrase key already in keyring
sudo: Error attempting to add passphrase key to user session keyring; rc = [1]
sudo: There is already a key in the user session keyring for the given passphrase.
sudo: Passphrase key already in keyring
sudo: Error attempting to add passphrase key to user session keyring; rc = [1]
sudo: There is already a key in the user session keyring for the given passphrase.
gnome-screensaver-dialog: Passphrase key already in keyring
gnome-screensaver-dialog: Error attempting to add passphrase key to user session keyring; rc = [1]
gnome-screensaver-dialog: There is already a key in the user session keyring for the given passphrase.
sudo: Passphrase key already in keyring
sudo: Error attempting to add passphrase key to user session keyring; rc = [1]
sudo: There is already a key in the user session keyring for the given passphrase.
sudo: Passphrase key already in keyring
sudo: Error attempting to add passphrase key to user session keyring; rc = [1]
sudo: There is already a key in the user session keyring for the given passphrase.
sudo: Passphrase key already in keyring
sudo: Error attempting to add passphrase key to user session keyring; rc = [1]
sudo: There is already a key in the user session keyring for the given passphrase.
sudo: Passphrase key already in keyring
sudo: Error attempting to add passphrase key to user session keyring; rc = [1]
sudo: There is already a key in the user session keyring for the given passphrase.
sudo: Passphrase key already in keyring
sudo: Error attempting to add passphrase key to user session keyring; rc = [1]
sudo: There is already a key in the user session keyring for the given passphrase.
sudo: Passphrase key already in keyring
sudo: Error attempting to add passphrase key to user session keyring; rc = [1]
sudo: There is already a key in the user session keyring for the given passphrase.
sudo: Passphrase key already in keyring
sudo: Error attempting to add passphrase key to user session keyring; rc = [1]
sudo: There is already a key in the user session keyring for the given passphrase.

Revision history for this message
Alexander Sack (asac) wrote :

should be fixed by NM 0.7 which is mostly a rewrite. If you have similar issues, open a new bug.

Changed in network-manager:
status: Incomplete → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

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