ccache using linux keyring

[David Howells]

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.

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

	Session
          |
	  +---> Kerberos
          |       |
          |       +---> TGT
          |       +---> nfs: home.cambridge.redhat.com
          |       +---> nfs: andromeda.cambridge.redhat.com
          |       +---> afs: cambridge.redhat.com
          +---> afs: redhat.com

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

 (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