After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 610270 - Keyring files are not automatically created when don't exist
Keyring files are not automatically created when don't exist
Status: RESOLVED FIXED
Product: gnome-keyring
Classification: Core
Component: general
2.29.x
Other Linux
: Normal normal
: ---
Assigned To: GNOME keyring maintainer(s)
GNOME keyring maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2010-02-17 15:44 UTC by Tomas Bzatek
Modified: 2010-03-10 14:31 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Tomas Bzatek 2010-02-17 15:44:12 UTC
Using unlocking via pam module, the new 2.29.90 gnome-keyring won't automatically create (at least) the login keyring when ~/.gnome2/keyrings is empty. This used to work properly with 2.26.0. The result is that a newly created user cannot store any password, nor he can create new keyrings in Seahorse either.

Steps to reproduce:
 1. create new user account, set a password (under root)
 2. login through gdm into gnome session
 3. notice that ~/.gnome2/keyrings is empty
 4. try to store any password (e.g. encrypted PDF in Evince)
 5. password won't get saved, ~/.gnome2/keyrings is still empty 

Seahorse reports no keyrings, whereas with 2.26 it displayed empty login keyring.

Storing session-only password works fine, session.keyring is created and Evince reuses the password. Same situation with Nautilus and gvfs mounts. Note that with my existing account with login and default keyrings, password storing works properly in the same scenarios.

I think this is what has been pointed out here: http://mail.gnome.org/archives/gnome-keyring-list/2010-February/msg00001.html
Comment 1 Stef Walter 2010-02-18 15:54:15 UTC
I think this needs two fixes. 

 * Number one, libgnome-keyring should automatically create a default keyring, similar to previous behavior.
 * Two, on startup with PAM module login.keyring should be set to default keyring.
Comment 2 Stef Walter 2010-02-18 17:22:13 UTC
First part of the fix committed to libgnome-keyring:

commit 5e37e8cc09712fd8cab60e42636f260f23bacd7e
Author: Stef Walter <stef@memberwebs.com>
Date:   Thu Feb 18 17:18:48 2010 +0000

    Can create a new default keyring when creating item.
    
    When no default keyring exists, and creating an item, and
    the default keyring was the desired keyring for the item,
    prompt to create a new default keyring.
    
    This mirrors the behavior in the old gnome-keyring-daemon.
    However this functionality has now been moved to the library.
Comment 3 Stef Walter 2010-02-18 17:50:02 UTC
Another fix to the daemon:

commit 070ffc3a9cdc589e7905f6afac8a8d379e745d8a
Author: Stef Walter <stef@memberwebs.com>
Date:   Thu Feb 18 17:47:18 2010 +0000

    [secret-store] Allow specifying CKA_ID when creating collection.
    
    This is necessary to allow creation of the login keyring, which
    needs a specific CKA_ID. Also we return an already existing
    collection if the ID matches one that already exists. This is
    similar to the behavior of item creation.
Comment 4 Stef Walter 2010-02-18 18:02:20 UTC
And finally this should fix the last bit of the problem. 

Thanks for catching this. Much appreciated.


commit de56d02feddfd6eb511412a3703774950b791151
Author: Stef Walter <stef@memberwebs.com>
Date:   Thu Feb 18 17:59:32 2010 +0000

    [dbus] When no default keyring set, use login keyring.
    
    This is similar to the previous behavior of gnome-keyring-daemon
    and also allows us to not set a default keyring when creating
    login keyring.
    
    Eventually this and other alias logic, needs to move into the
    pkcs11 secrets module.
Comment 5 Tomas Bzatek 2010-03-10 14:31:11 UTC
Thanks, works like a charm!