ccache using linux keyring

[Kevin Coffman]

David Howells <dhowells at redhat.com> wrote:
> Kevin Coffman <kwc at citi.umich.edu> 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 http://people.redhat.com/~dhowe
> > 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):

  Session
     |
     +---> 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/screamer.citi.umich.edu at CITI.UMICH.EDU
     |       +---> nfs/troy.citi.umich.edu at CITI.UMICH.EDU
     |       +---> pop/citi.umich.edu 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/tremors.itd.umich.edu 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