ccache using linux keyring

[Kevin Coffman]

> From: Sam Hartman [mailto:hartmans at mit.edu]
> 
> >>>>> "Kevin" == Kevin Coffman <kwc at citi.umich.edu> writes:
> 
>     Kevin> After discussing this here with Bruce, I think having more
>     Kevin> than one ccache in the session ring is unnecessary.  If you
>     Kevin> want to do this sort of thing, you would do the equivalent
>     Kevin> of a setpag and get into a new session keyring.  That still
>     Kevin> leaves the problem of gssd finding the ccache w/o
>     Kevin> environment variables.  However, naming the keyring
>     Kevin> something like "krb5ccache:<residual>" and having only one
>     Kevin> ccache in a session ring would allow it to work.
> 
> I think we disagree.  I think we'd like to see something more like KFM
> semantics unless there is a good reason not to.  So we would like to
> support multiple ccaches per session.
> 
> I still am uncomfortable with Jeff's naming suggestions.  I can think of a
> lot of cases where you would have multiple tickets for the same service:
> 
> * U2U tickets for different TGTs
> 
> * postdated or invalid tickets
> 
> * different encryption types
> 
> * New extensions to Kerberos that make tickets distinguishable in ways
>   that current tickets are not distinguishable.
> 
> I think it is fine to include the service name in the ticket, but I think
> you need to support multiple tickets that have the same service name.
> 
> --Sam

As it turns out, I cannot locate the cache using either half of the name as
I thought I could.  (I thought I could search for "krb5ccache:*" or
"*:<residual>", but strcmp() is the match function for "user" keys.  This
would actually still be useful in locating the principal information key
within the ccache keyring.  For now, this still has to be a well-known name
like "krb5_princ" instead of "krb5_princ:kwc at UMICH.EDU".)

I will keep the support for multiple ccache keyrings within a session.  So I
do need a key to help me (gssd) find the correct ccache keyring.  (Because
gssd will not have the user's environment variables.)  The ccache
implementation will still use the environment variable -- actually whatever
name is passed down as "<residual>" -- to locate the ccache to use.

The naming of the individual keys within the ccache keyring is not important
to the ccache implementation as I have it.  It uses the keys' serial
numbers, not their names, to find them.  The naming would only be important
if future kernel code was written to locate a specific key for some reason.
I can add enctype info to the name.  Is there any other naming distinctions
that might be useful?  (Jeff, I'd like to understand what OpenAFS has in
mind for the token of the future, and how they'll be obtained.)

I can also extract expiration time from the cred and set the key's
expiration when adding the key into the keyring.  (This would have the
effect of the expired keys "disappearing" when they expired.  This would be
a visible change from the current ccache semantics.  So I don't plan on
doing that unless someone thinks it would be a good idea.)

The PAGE_SIZE limit on the keyring contents would limit a ccache to
approximately 1000 tickets.  Does that sound like it will be a problem?

Kevin