ccache using linux keyring

[Sam Hartman]

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