ccache using linux keyring
dhowells at redhat.com
Wed Apr 13 16:35:19 EDT 2005
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
Can you give an example of what you mean? Perhaps as a tree:
| +---> 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
More information about the krbdev