This is quite easy to reproduce with any of the following:

 * Create a brand new user
 * rm .gnome2/keyrings/{login.keyring,user.keystore}
 * Remove "User Keys" password entry in seahorseand rm .gnome2/keyrings/user.keystore

and then logging out and back into GNOME.

This doesn't happen when just restarting gnome-keyring-daemon, I strongly suspect it's due to pam_gnome_keyring.so.

This is an easier reproducer for developers, which mimics what the PAM module and autostart .desktop files do, but without the requirement to log out/in:

killall gnome-keyring-daemon
rm .gnome2/keyrings/*
export `echo s3kr1t | gnome-keyring-daemon --daemonize --login`
export `gnome-keyring-daemon --start --components=secrets`

This will put "s3kr1t" into the "User Keys" password in login.keyring. Running "seahorse" will show that. (Unfortunately there does not seem to be a CLI tool to dump a keyring).

A naive fix for this to stop storing the passphrase is to disable the gkd_login_attach_secret() call in init_pin_for_uninitialized_slots() (daemon/login/gkd-login.c). However, I'm still not sure why g-k stores the login password in itself in the first place -- it doesn't make any sense to me. Stef, what is the purpose of this?

Also, we still need some more code to remove the password from the keyring again for upgrades from the faulty versions.

> Stef, what is the purpose of this?

More precisely, this is apparently used to unlock the user.keystore, but I have no idea how to actually use that keyring. It's empty (well, 207 bytes) on all my machines and accounts, and in seahorse I do not see an option to put credentials into there either.

Created attachment 159244 [details] [review]
first draft for a patch

This is a first crappy patch which stops the user password from getting into the keyring, and also remove it during upgrade.

Let's call it a basis for discussion. :-)

Now I need to wait on Stef's comment what this ominous user.keystore is for. This patch will probably break it, but I don't see how to use it in the first place.

Thank you in advance!

Committed a similar fix. 

commit 4efbaf1a7567359a42967d98fd7fbd9fcb984930
Author: Stef Walter <stef@memberwebs.com>
Date:   Wed Apr 21 16:40:36 2010 +0000

    [login] Fix security problem storing user's login password in keyring.
    
    Don't store the user's login password in the keyring, which was being
    done when initializing the PKCS#11 user storage module.
    
    In addition put in a temporary fix which removes such passwords stored.
    This problem started during the 2.29.x betas, so anyone doing beta testing
    will be covered by this removal.
    
    Fixes bug #616174

The user.keystore stores certificates and private keys. Most people don't (yet) use these features. A password is required to initialize that component and prepare it for storage. We now use the login password for this.

But you're right, we don't strictly need to store it anywhere after initializing the key storage components. This is the result of moving and migrating that code over from the previous way of doing things, without properly identifying all the consequences of the new context the code is being run in. Sorry about that.

This patch results in a possible slight degradation in usability in specific use cases, such as when the user's login password is changed by root (and the PAM change password module hooks are not run). However I think this is an okay tradeoff, and can be remedied by better messages in related unlock prompts.

Please double check that this issue is fixed properly.

I don't see the patch in git, I contacted Stef again. Perhaps just a push failure?

Ah, there now. Thank you!

So aside from the password comparison this essentially has the same logic. I'm glad that I wasn't totally wrong. :-)