Red Hat Bugzilla – Bug 125682
Keyrings should be unlocked on authorized login
Last modified: 2007-11-30 17:10:44 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.6)
Description of problem:
I am in the process of writting a PAM module that executes
gnome-keyring-daemon and unlocks a user's default keyring using their
system password. The benefit is that the user finds his keyring
unlocked once he has logged in. This makes the use of gnome-keyring
An early version of pam_keyring is available at:
At this point, pam_keyring is not ready for production systems.
However, I would like solicit comments on the concept behind it.
Here are some notes about pam_keyring 0.0.1 currently:
1. I am working on an SELinux policy for pam_keyring (see
pam_keyring_macros.te). In order to do this right I will have to make
some changes to some other policies. At this point, ask SELinux to
not enforce its policies if you want to experiment with pam_keyring.
2. Currently, gnome-session tries to start gnome-keyring-daemon.
This does not make sense if pam_keyring has already done so. Make the
following change to gnome-session in order to fix this (I plan on
submitting a patch soon):
- gsm_keyring_daemon_start ();
+ if (getenv("GNOME_KEYRING_SOCKET") == NULL)
+ gsm_keyring_daemon_start ();
3. Although I have read that calling gnome_keyring_unlock with NULL
as the first argument should unlock the default keyring, this does not
seem to be the case. Replace "test" in pam_keyring.c with the name of
your default keyring.
4. Ensure the password that unlocks your default keyring is the same
as your system password.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Note that you have to enter a password to log in and then enter
another password to unlock your GNOME keyring.
I fixed cvs HEAD to unlock the default keyring if you pass NULL (that
can't hurt). You can also use the gnome_keyring_get_default_keyring()
What OSX does is:
By default, each Mac OS X login account has one keychain (for a new
login on Mac OS X v10.3, this keychain is named login.keychain);
however, a user or application can create as many keychains as
desired. The login keychain is automatically unlocked during login if
it has the same password as the userâs login account password. When
first created, the login keychain is also the default keychain. The
default keychain is used to store newly-created keychain items unless
a different keychain is specified in the function call; certain other
Keychain Services functions also use the default keychain when no
other keychain is specified. The user can use the Keychain Access
utility to designate another keychain as the default; however, the
login keychain doesnât change.
Maybe something like that would be good, because you might not always
want to automatically unlock all your passwords.
Another thing i worry about is daemon shutdown. gnome-session
currently shuts down the daemon on logout, because we don't want the
process running when the user logs out (thats a security problem). Can
this be solved somehow?
Killing the daemon is handled by implementing a PAM close session
function, so this is not a problem.
A note on pam_keyring 0.0.1 that I forgot to mention: currently, my
UID/GID is hard coded into pam_keyring.c. If you want to try this
unstable version then you will need to do a s/500/<your UID>/g.
Obviously, UIDs will be automatically looked up given the user's login
My intention with 0.0.1 is to get some feedback early in the
I'm really not the right version to look at pam stuff, if you want
better feedback, try mailing privately to email@example.com. He's our
pam guy, and he's interested in gnome-keyring too.
I think we should do this for FC5. Nalin, what are your thoughts on this?
I don't think it's a good idea. Or rather, that it may be a good idea, but that
the implementation might end up making things more inconsistent for users than
the current, separated state.
If the keyring is password-protected, and you want to unlock it with the user's
login password, you've implicitly made at least two assumptions:
1) if the user changes her password, you're in a position to change the password
you've used to lock the keyring
If the user's on a network, and changes her password through any means you
don't control (think about the "go to this web page to reset your password"
case), the one-password functionality "breaks" unexpectedly.
2) the user uses a password to log in
If the user is using a smart card, one-time passwords, or is logging in
remotely using strong authentication such as a public key or a GSSAPI mechanism,
it just plain doesn't work because no password is exchanged. The problem being
that we want to increase the use of these technologies.
Okay, that's enough resistance for me.
While I agree with the considerations in comment #5, I DO believe that this is
an important bug and should be re-opened. How about a "Attempt to unlock
keychain with login password" option?
By closing this bug, you are ignoring the current usability problem...
Case: User is using a notebook, completely mobile, and 95% of the time uses
wireless access with it (this is my situation, and I believe that you will find
MANY others in the same situation). User adds /usr/sbin/nm-applet to the Gnome
startup preferences so that nm-applet start at each login.
Result: When user enters login and password for GDM, he is immediately accosted
for anoter login/password (which may be the same) to start nm-applet. By the
way, THIS HAPPENS EVEN IF THERE IS A HARD WIRED CONNECTION AVAILABLE.
I believe that this is an unacceptable outcome for this case. Just my $0.02,
and I'll work around it in the end, but this is just the kind of behavior that
causes resistance to using Linux on the desktop.
I completely agree with Bernard Johnson. See the following thread, exctly
raising this problem for network-manager.
Please do not understimate this point. It is quite annoying to have to type 3
passwds (login, ssh-agent, gnome-keyring) just to connect on a laptop.
Ideally I would like just to type one, by default.
Maybe it would be easier and better to try to use the ssh passphrase from
gnome-ssh-askpass. Currently this application (or ssh below) is already
intelligent enough to use my one time given passphrase to unlock both my ssh1
and ssh2 keys - or, if the passphrases are different, it asks me again for the
second. Why not extend such an application to ask for passphrases (but first try
to reuse them) for things like NM?
This could prove to be easier to handle than plugging into the system login dialog.
Or the other way round, delegate to gnome-keyring to handle also ssh-agent work.
Or as a minimial solution, allow the user to define key-rings without passwd
(even the default one?), or for which passwd is reuired only for modification
and clear-text display of the key. So for instance I would create a keyring for
NetworkManager ono my laptop so that it asks me the keyring passwd only if I
want to change the WEP key of some network, or read it in clear text.
As this bug is still assigned to me (though it shouldn't, really, but that is
another matter) I'm going to reopen it, because, as noted in the comments above
this is a real usability issue: applications need a secure way of storing secrets.
It just so happens that the GNOME way of doing this is by using gnome-keyring
which is one API of many that performs this service (other API's that come to
mind are the KDE wallet and the NSS from Mozilla). My view is that this largely
a distribution headache we need to solve in Fedora: we need to be able to unlock
multiple keyrings (containing secrets) upon an authorized login.
Change the Summary to adequately reflect the problem at hand.
Looks like this is getting some momentum upstream:
NetworkManager Work Items - http://live.gnome.org/NetworkManagerToDo
Bug 331529 â [enh] system-wide config to stop annoying keyring-on-login dialog -
Bug 312877 â GDM login should open the keyring -
Bug 326925 â need for a keyring that is unlocked than logging in -
I have launched my initial release of pam_keyring, since taking over the project
from Mike. It can unlock the default, or a specified keyring using the login
password. The limitation to this is if you specified a different password for
your default keyring you are kind of hosed because gnome-keyring doesn't support
changing passwords yet ( FYI, I am working on a patch that should be submitted
soon that will take care of this limitation ). Other than that all other bugs
and limitations have been cleaned up I think. Feedback is of course appreciated.
Can you post the source rpm as well?
I personally think this looks good; so in the event the login password is
changed so it's different from the gnome-keyring password, how about popping up
a dialog that instructing the user to change his gnome-keyring password to the
new password? Obviously this requires the old password so great care must be
taken not to confuse the user...
Of course, the real fix involves Single Sign On (btw, Nalin, how is that going?)
but I guess this works in the interim; personally I'm sick and tired of having
to unlock gnome-keyring every time I want to use VPN or my encrypted removable
Alex, Nalin, what do you think?
I generally like the idea. I agree that having to sync the keyring password with
the user password is a weakness, but that doesn't imho mean we shouldn't do this.
However, I really don't know much about pam and our work on single sign-on which
this clearly is a part of, so I'm not the best person to ask. (Also, I'm busy
with other stuff at the moment.)
Sorry about the delays guys. I forgot to add myself to the CC list of this bug,
taken care of now. I have thought about both these situations and here is the
rundown of my thoughts. Feedback is definitely welecomed.
Change of password on Login. This was originally implemented in Mike's
gnome-keyring-tool. I removed it because this has to be written into
gnome-keyring with the api's for client usage. I have started writing this, but
work has pulled me away from it temporarily. I will get it done soon I swear.
Once that patch is implemented I can easily add this functionality back into
pam-keyring-tool and the pam module and we are good.
Passwords out of sync. If the above is done correctly then this shouldn't
happen very much. If it does I am thinking this should be a boolean that is
stored in the keyring that gnome-keyring-ask should pick up on. This gives you
a different dialog something like, "this password is set to be unlocked on
login, however the passwords differ. Please unlock this keyring with your old
password and then set it's current password to use the one you logged in with."
That is a quick rough dialogue, but I am sure you get the idea.
I didn't know anything about pam when I started this either, all my experience
was researching the existing pam modules and trying to get everything to fit
together. I think I have crossed all my t's and dotted my i's. I am hoping for
feedback from the pam list to really cement the fact I have done a decent job.
I just knew this was a necessity for this design to work.
This is only my first revision to get stuff to work correctly, get community
support, and give the technology a good baseline. Ultimately I see the proper
solution to be a special "login" keyring that is unlocked with and kept in sync
with the system authentication password and then contains all the keyrings and
associated passwords that a user can select to be unlocked on login.
We then add the gui changes to gnome-keyring-manager and gnome-keyring-ask to
have checkboxes for the user to select the "Unlock on login" box and the
keyring-daemon automagically adds that keyring and necessary password to an
encrypted keyring stored on the filesystem that can be read on login once the
user has authenticated. This allows us to then have a NetworkManager, or
Evolution, or Firefox keyring with different passwords, but not needing to keep
unlocking or keeping track of them all.
Just my thoughts. I think I have nailed down a bunch of the use cases, but I
might be wrong, or not in sync with what the community needs.
I also forgot to add. I haven't built a source rpm, but can definitely do so if
you definitely want one. In the contrib subdirectory of the tarball there is
the spec file I used to build the rpm.
Added the source rpm to the site.
With the recent round of updates on Core 5 updates-testing, pam_keyring stopped
working. I have fixed all known issues and updated the rpm's and tarballs.
Please go to http://www.hekanetworks.com/pam_keyring/ for the new versions.
I just submitted a pam_keyring 0.0.7 package to Fedora Extras. Please see:
I think that we are just a few steps away from having a fully implemented pam
module. Support for changing passwords was committed to gnome-keyring cvs
today. I have a patch pending for password changing using
gnome-keyring-manager. I will now get pam_keyring implemented to properly
handle system password changes via passwd. That will give us a good solution
for phase one. I will try and get that functionality implemented by the end of
The pam_keyring module is now available in Fedora Extras' Rawhide tree.
Closing since pam-keyring is in fedora extras.