Bug 125682 - Keyrings should be unlocked on authorized login
Summary: Keyrings should be unlocked on authorized login
Alias: None
Product: Fedora
Classification: Fedora
Component: gnome-keyring   
(Show other bugs)
Version: rawhide
Hardware: All Linux
Target Milestone: ---
Assignee: Alexander Larsson
QA Contact:
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2004-06-10 00:57 UTC by W. Michael Petullo
Modified: 2007-11-30 22:10 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-14 12:34:08 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description W. Michael Petullo 2004-06-10 00:57:28 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.6)
Gecko/20040510 Epiphany/1.2.4

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
more transparent.

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):

How reproducible:

Steps to Reproduce:
Note that you have to enter a password to log in and then enter
another password to unlock your GNOME keyring.

Additional info:

Comment 1 Alexander Larsson 2004-06-10 08:13:26 UTC
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?

Comment 2 W. Michael Petullo 2004-06-10 14:13:36 UTC
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
name soon.  

My intention with 0.0.1 is to get some feedback early in the
development process.

Comment 3 Alexander Larsson 2004-06-11 06:42:26 UTC
I'm really not the right version to look at pam stuff, if you want
better feedback, try mailing privately to nalin@redhat.com. He's our
pam guy, and he's interested in gnome-keyring too.

Comment 4 David Zeuthen 2005-06-13 18:06:31 UTC
I think we should do this for FC5. Nalin, what are your thoughts on this?

Comment 5 Nalin Dahyabhai 2005-09-12 19:49:32 UTC
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.

Comment 6 W. Michael Petullo 2005-09-18 00:00:14 UTC
Okay, that's enough resistance for me.

Comment 7 Bernard Johnson 2005-09-20 16:47:53 UTC
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

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.

Comment 8 Giuseppe Castagna 2005-10-24 22:14:50 UTC
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. 


Comment 9 Jens Lautenbacher 2005-10-25 08:47:48 UTC
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.

Comment 10 Giuseppe Castagna 2005-10-25 09:06:59 UTC
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.

Comment 11 David Zeuthen 2005-10-25 20:11:51 UTC
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.

Comment 12 David Zeuthen 2005-10-25 20:16:08 UTC
Change the Summary to adequately reflect the problem at hand.

Comment 13 Bernard Johnson 2006-03-10 22:39:35 UTC
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 -

Comment 14 Jon Nettleton 2006-03-26 12:48:01 UTC
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.


Comment 15 Bernard Johnson 2006-03-26 15:38:48 UTC

Can you post the source rpm as well?

Comment 16 David Zeuthen 2006-03-26 20:21:09 UTC
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?

Comment 17 Alexander Larsson 2006-03-27 08:21:33 UTC
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.)

Comment 18 Jon Nettleton 2006-03-29 03:02:52 UTC
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.

Comment 19 Jon Nettleton 2006-03-29 03:07:47 UTC
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.

Comment 20 Jon Nettleton 2006-03-30 14:03:16 UTC
Added the source rpm to the site. 

Comment 21 Jon Nettleton 2006-04-02 14:45:32 UTC
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.  

Comment 22 W. Michael Petullo 2006-04-03 21:10:25 UTC
I just submitted a pam_keyring 0.0.7 package to Fedora Extras.  Please see:


Comment 23 Jon Nettleton 2006-04-19 22:52:22 UTC
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 weekend.

Comment 24 W. Michael Petullo 2006-06-25 16:51:21 UTC
The pam_keyring module is now available in Fedora Extras' Rawhide tree.

Comment 25 Alexander Larsson 2006-08-14 12:34:08 UTC
Closing since pam-keyring is in fedora extras.

Note You need to log in before you can comment on or make changes to this bug.