ccache using linux keyring
kwc at citi.umich.edu
Thu Apr 14 10:14:34 EDT 2005
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
> > 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/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
More information about the krbdev