Ubuntu
gnome-keyring package

gnome keyring manager cannot create permanent keyrings

Bug #146724 reported by aldebx
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
GNOME Keyring
Fix Released
Critical
gnome-keyring (Ubuntu)
Fix Released
Low
Ubuntu Desktop Bugs

Bug Description

Binary package hint: gnome-keyring-manager

versions:
ii gnome-keyring 2.20-0ubuntu4
ii gnome-keyring-manager 2.20.0-0ubuntu2
ii libgnome-keyring0 2.20-0ubuntu4
ii libpam-gnome-keyring 2.20-0ubuntu4
ii libpam-mount 0.18-4

The applet cannot load persistent keyrings (and as a result network manager always prompts to create one at logon) and the application is actually useless for me. (I wouldn't consider this as Low in priority...)

As you can read in October 14 post hereafter the problem seems strictly related to the use of libpam-mount together with gnome-keyring.

If I open that applet it shows only session keyring, if I manually try to create another keyring (such as session or login) it first lists it in keyrings list however when I click on the keyring a window pops up saying "no such keyring".

If I run gnome-keyring-manager through the shell this problem is reported as "(gnome-keyring-manager:6822): Gnome-Keyring-Manager-WARNING **: Failed to get keyring info."

of course when I close and restart keyring manager no other keyrings other than session are listed.

In .gnome2/keyrings there are actually listed several keyrings: default default1.keyring default2.keyring etc, all those network manager applet or me tried to create, however none of them are actually recognised by the applet

I tried deleting contents of .gnome2/keyrings and also tried using a new user account but no chance to get it working anyway!!

See original description
Revision history for this message
aldebx (aldebx) wrote :

more error messages provided by nm-applet

** (nm-applet:24977): WARNING **: couldn't connect to daemon at $GNOME_KEYRING_SOCKET: /tmp/keyring-Zpi3Sl/socket: Connection refused

** (nm-applet:24977): WARNING **: couldn't communicate with gnome keyring daemon via dbus: The name org.gnome.keyring was not provided by any .service files

** (nm-applet:24977): WARNING **: <WARN> nmi_save_network_info(): Error saving secret for wireless network 'myhome' in keyring: 2

Revision history for this message
aldebx (aldebx) wrote :

Seems this bug as already been addressed and will be fixed in gnome 2.20.1 release of the keyring manager.
http://bugzilla.gnome.org/show_bug.cgi?id=483288

aldeby (aldeby-merged)
Changed in gnome-keyring-manager:
status: New → Fix Committed
Sebastien Bacher (seb128)
Changed in gnome-keyring-manager:
assignee: nobody → desktop-bugs
importance: Undecided → Low
Revision history for this message
Sebastien Bacher (seb128) wrote :

gnome-keyring (2.20-0ubuntu3) gutsy; urgency=low

  * debian/patches/90_from_svn_load_new_keyrings.patch:
    - patch from SVN, "Add newly created keyrings to our list of loaded keyrings
      (LP: #146724)

 -- Sebastien Bacher <email address hidden> Sat, 06 Oct 2007 12:27:58 +0200

Changed in gnome-keyring:
status: Fix Committed → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in gnome-keyring:
status: Unknown → Fix Released
Revision history for this message
aldebx (aldebx) wrote :

see also http://bugzilla.gnome.org/show_bug.cgi?id=483288

with gnome-keyring (2.20-0ubuntu4) gutsy the problem I reported is not yet solved, hereafter some more details I found out:

the problem described in this bug (that is very similar to the one of GNOME bug
476644) seems to be caused by the interaction between gnome-keyring-daemon and
libpam-mount, hence so few people who reported this bug (only those that use libpam-mout to mount encrypted partitions at login experience it)!

I can say without any doubt that gnome-keyring works perfectly with default files
/etc/pam.d/gdm
and
/etc/pam.d/login
However if at the end of these files (and specifically /etc/pam.d/gdm) I include line @include common-pammount
and reboot I get the reported problem: no keyrings are going to be loaded! and NetworkManager as well as samba and other applications keep asking for the password each time. and also gnome-keyring keeps asking also for the master password in order to create a new default keyring (which it indeed creates in $HOME/.gnome2/keyrings directory but cannot load).

as I wrote in GNOME bug 483288 if I kill the gnome-keyring-daemon and then
start it again having pammount enabled in both mentioned files I AM able to bring the keyring working again as expected.
Unfortunately I should do this (killall then restart) at every reboot.

aldeby (aldeby-merged)
Changed in gnome-keyring:
status: Fix Released → New
Revision history for this message
aldebx (aldebx) wrote :

this is just to add that when string '@include common-pammount' is included in the above mentioned pam.d files pam-mount works as expected, it is only gnome-keyring that does not.

For the actual (default) configuration of my gdm and login files please refer to the mentioned http://bugzilla.gnome.org/show_bug.cgi?id=483288 to whom they are attached.

aldeby (aldeby-merged)
description: updated
Revision history for this message
Sebastien Bacher (seb128) wrote :

Not confirming the issue, maybe you should reopen the upstream bug

Revision history for this message
aldebx (aldebx) wrote :

GOSH!!! After this bug has driven me totally crazy I finally focused out the actual cause of the described issue: character '?'.

Yes that is, if you choose a password for gnome keyring containing the ? character the keyring cannot open the keyrings any more reproducing the described misbehavior.

Changing the password solves the problem.

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

The bug should be fixed in hardy now

Changed in gnome-keyring:
status: New → Fix Released
Bug Watch Updater (bug-watch-updater)
Changed in gnome-keyring:
importance: Unknown → Critical
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

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