ccache using linux keyring

[Jeffrey Hutzelman]

On Thursday, April 14, 2005 11:19:44 AM -0400 Sam Hartman 
<hartmans at mit.edu> wrote:

>>>>>> "Kevin" == Kevin Coffman <kwc at citi.umich.edu> writes:
>
>     >> >>>>> "Jeffrey" == Jeffrey Hutzelman <jhutz at cmu.edu> writes:
>     >>
>     Jeffrey> On Wednesday, April 13, 2005 12:40:50 PM -0400 Kevin
>     Jeffrey> Coffman
>     Jeffrey> <kwc at citi.umich.edu> wrote:
>     >>  >> 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.  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.)
>     >>
>     Jeffrey> Why not name them for the service principal?
>     >>  I'm concerned that there may be circumstances where you want
>     >> to have duplicate or semi-duplicate tickets.  I'm concerned
>     >> that other ccache types do not work this way and it seems
>     >> dangerous to have different semantics.
>
>     Kevin> I'm not sure I understand your concern.  From the user-land
>     Kevin> Kerberos library view, this should look like any other
>     Kevin> ccache type.
>
> Jeff is proposing having different semantics (being able to store only
> one ticket per service principal) than other ccaches.

That would be an effect of my proposal, unless the implementation goes out 
of its way to prevent that (say, by doing something to make the names 
unique).  I agree with Sam that there are circumstances in which you might 
have multiple tickets for the same service principal, and the ccache 
backend needs to deal with that.

Also, it is entirely possible to have a service ticket in which the client 
and service principals are the same.