ccache using linux keyring

Kevin Coffman kwc at
Thu Apr 14 10:14:34 EDT 2005

David Howells <dhowells at> wrote:
> Kevin Coffman <kwc at> wrote:
> > I have a preliminary ccache implementation for Linux using the new 
> > kernel keyring support as the storage medium.  (See 
> > Documentation/keys.txt in the patches at
> > lls/keys/ for documentation on the keyring support.)
> > 
> > Before I get too far with it, I'm looking for comments/suggestions on 
> > what I currently have implemented and my proposed change.
> > 
> > The current implementation uses a new keyring created in the 
> > session-specific keyring (KEY_SPEC_SESSION_KEYRING) to represent a 
> > user's credentials cache file.
> That seems reasonable. One could argue for the user keyring, but it's okay in
> the session keyring too.

I chose session because that what seemed more pag-like.  It looked
to me like JOIN_SESSION_KEYRING is the newpag equivalent.
Is that wrong?

> > The principal information and each ticket are stored in this keyring as an
> > individual key.  The name of the keyring matches the 'residual' name as
> > passed to the resolve function and found in KRB5CCNAME.  The principal
> > information is kept in a key named 'krb5_princ' and each ticket is kept in 
> a
> > sequentially numbered key 'krb5tkt_000000', etc.  (These individual key
> > names are just for reference, their key_serial is what is really kept track
> > of.)
> Can you give an example of what you mean? Perhaps as a tree:

OK, using the new naming suggested by Jeff, here is what I would see
(with my UMICH.EDU credentials cache "active" for gssd):

     +---> krb5_cc_active		(contains 0x00004f12)
     +---> /tmp/krb5cc_20010_XF45C2	(keyring id is 0x23cd)
     |       |
     |       +---> kwc at CITI.UMICH.EDU   (principal info)
     |       +---> krbtgt/CITI.UMICH.EDU at CITI.UMICH.EDU
     |       +---> nfs/ at CITI.UMICH.EDU
     |       +---> nfs/ at CITI.UMICH.EDU
     |       +---> pop/ at CITI.UMICH.EDU
     |       +---> afs at CITI.UMICH.EDU
     +---> /tmp/krb5cc_20010_umich	(keyring id is 0x4f12)
             +---> kwc at UMICH.EDU        (principal info)
             +---> krbtgt/UMICH.EDU at UMICH.EDU
             +---> imap/ at UMICH.EDU

This assumes that my default realm is CITI.UMICH.EDU and I've gotten
several ticket for the CITI.UMICH.EDU realm.  Then I've done
	% setenv KRB5CCNAME KEYRING:/tmp/krb5cc_20010_umich
	% kinit kwc at UMICH.EDU
and then ran the utility to make /tmp/krb5cc_20010_umich my active
ccache.  gssd will then try to use my UMICH.EDU tickets to get
service tickets to negotiate NFSv4 gss contexts.

> > This still leaves our gssd with no way to easily and deterministically 
> > find the right credentials cache (keyring) to use for a given request.
> Some points for you to consider, if you haven't already done so:
>  (1) A key's description should be set to something appropriate to the
>      service that's going to be looking for it.
>      For instance, NFSv4 might want a key of, say, type "nfs" and description
>      "mynfsserver.mydomain". Alternatively, if the NFS client maintained its
>      own mappings of NFS server -> Kerberos realm, then setting the
>      description to the Kerberos realm would be good. The key's payload would
>      indicate what sort of ticket it is: KRB4, KRB5, sillycryptothingy, etc
>      and the data used to deal with a key of that type.
>  (2) It is permitted for a key's description to contain the keys to match
>      more than one search criterion; this is one of the reasons for having
>      key type provide the matching function.
>  (3) The request_key() search algorithm expects to be dealing with the key's
>      description. The description may get passed on to /sbin/request-key.
>  (4) You can always make use of the "user" key type to hold keys that you
>      don't want to write your own key type for.
>  (5) Users have a key count quota and a key allocation quota.

This is one issue that I am concered with.  I could look at the code...
but is the quota configurable?

>  (6) The key management interface isn't 100% set in stone yet; it can still be
>      changed. For insance, it would be possible to request key instantiation
>      occur in a keyring under the default; so a process may set the default
>      keyring to be its process keyring, but an /sbin/request-key service
>      adding a kerberos key could insist on using a "Kerberos" keyring under
>      that.
> David

More information about the krbdev mailing list