Users should probably actually be setting the unlock password for their login keychain to match their login password -- not simply leaving it empty. Reproducible: Always Actual Results: >>> Messages generated for package gnome-base/gdm-2.20.9 by process 11593 on 20090106-115116 EST: LOG: postinst [...snip...] For autologin to unlock your keyring, you need to set an empty password on your keyring. Use app-crypt/seahorse for that. Expected Results: >>> Messages generated for package gnome-base/gdm-2.20.9 by process 11593 on 20090106-115116 EST: LOG: postinst [...snip...] For autologin to unlock your keyring, you need to set the unlock password for your login keyring to be identical to your user login password. If your user login password changes, you will have to also change the unlock password for your login keyring to match. A less secure alternative is to set an empty password for your login keyring. To manage the unlock password for your login keyring, use the preferences menu of app-crypt/seahorse.
just reread the elog information, you are mistaken. the first part is about autologin, just check upstream documentation for confirmation. the second part is not really relevant since default configuration of pam with USE="gnome-keyring" will do the proper thing transparently. It's a reminder for people doing weird things.
(In reply to comment #1) Sorry if this was in error. I don't understand what you mean by "first part" and "second part". The only "part" I am talking about is this: "For autologin to unlock your keyring, you need to set an empty password on your keyring. Use app-crypt/seahorse for that." My point is that I suspect it is a security hole to have an empty password set on the unlock keyring. Since the unlock keyring WILL automatically unlock upon login if it's password matches that supplied to GDM, then it may be more secure to set a password on the login keyring (which would appear to be consistent with its original design). Regardless of what upstream documentation says, setting an empty unlock passord for a keychain seems to me very much a kludge, in addition to a security hole. But now that I have explained myself, I will assume you make the correct decision already and will leave it to you to reopen this if my explanation has any validity. Thank you.
(In reply to comment #2) Reworded for clarification (improper Gnome terminology above): My point is that I suspect it is a security hole to have an empty unlock password set on the login keyring. Since the login keyring WILL automatically unlock upon login if it's password matches that supplied to GDM (and not just if it's empty), then it may be more secure to actually SET a password (and not leave it empty), It was probably designed to receive a password for a reason. Regardless of what upstream documentation says, setting an empty unlock passord for a keychain seems like a kludge to me and a security vulnerability. But now that I have explained myself, I will assume you make the correct decision already and will leave it to you to reopen this if my explanation has any validity. Thank you.
Also, I am not sure what upstream documentation you are referring to. Here is what it says at http://live.gnome.org/GnomeKeyring/Pam: -------------------------------------------------------------------------- Gnome Keyring: Automatic Unlocking / PAM: [... irrelevant stuff...] # Upon authenticating the user, the PAM module tries to unlock the 'login' keyring with the password entered by the user. * If the 'login' keyring does not exist it is created with the user's password. * If the 'login' is the first and only keyring it will become the default keyring. # When the PAM session is closed, if the PAM module started gnome-keyring-daemon it is killed. # When the user changes their password, the PAM module changes the password of the 'login' keyring to match. * Again, here gnome-keyring-daemon is started if necessary. * If root changes the password, or /etc/shadow is directly edited then due to the lack of the old password, the 'login' keyring cannot be updated. ------------------------------------------------------------------------- So, I'm sure it's my own oversight or ignorance, but I fail to see how creating the login keyring with a BLANK password fits into this procedure. Is there other documentation I have overlooked? Thank you for your time, and I apologize if this is unnecessary. At this point, I simply do not see how having a blank password for a keyring that protects my passphrases for things like ssh and gpg keys can be anything but a security vulnerability.
After further testing, here are my observations: 1) If the user sets a blank password for they login keychain, it uses non-encrypted storages. The entire keychain file is in plaintext, including passwords. When the user changes his/her password, the file remains in plaintext with no encryption. 2) If the user allows gnome keychain to create a login keyring for him/her, the keychain is created with the current unix/pam password, not a blank one, and the file is encypted. 3) Contrary to the Gnome documentation (as cited above), when the user changes user password via pam, the login keyring password is not changed by PAM to be kept in sync. So, I assume that #3 is why we are instructing users to do #1. But it is pretty clear to me that having the login keyring stored in plaintext in the home directory, protected only by file permissions, is a security vulnerability. It frequently contains ssh, email, network, or other passwords. And using a blank password seems to result in exactly that. Now, my question would be, "Is this working for other people?". Do we have a problem with the way we have set up gnome-keyring in PAM, or is this a known problem with gnome keyring? Either way, it's unacceptable from a security standpoint -- assuming I have not simply implemented it incorrectly myself, which I freely admit is entirely possible.
since you don't seem to get what is written in clear wors, I'll try again: "For autologin to unlock your keyring, you need to set an empty password on your keyring. Use app-crypt/seahorse for that." this is about _auto_ login, the thing where you don't have to type your user name and password very much like windows xp does when you have a single user unprotected setup (which is the default btw). This comment in solely intended for users wanting *automatic* keyring unlocking for *automatic* login. There is no other security break than the one already set up by the user. Now please also reread upstream pam documentation: "# When the user changes their password, the PAM module changes the password of the 'login' keyring to match." in other words, the *user* changes his/her *own* password and so gnome-keyring does the same on the login keyring. If root does it, it won't work because root doesn't know about user password so there is no security hole here either. please read carefully before jumping to conclusions. Thanks.
(In reply to comment #6) Thank you for your reply. I apologize if I'm trying your patience. I did not understand they were referring to GDM auto-login. Thank you for clearing that up. (I can't believe people actually use that.) And that does indeed render this bug invalid. Sorry for wasting your time. This does not, however, change the fact that this... "# When the user changes their password, the PAM module changes the password of the 'login' keyring to match." ... is broken. But that would be a pam or gnome-keychain bug. (As I have noted in my observations above, when the user changes their unix/pam password, it will only change the unlock password of the login keyring if it is unset. Once the login keyring has an unlock password (regardless of how it was set), if the user changes their unix/pam password, the login keyring's password is NOT kept in sync, which I understand to be the intended functionality per the documentation.)
