ccache using linux keyring

[Kevin Coffman]

> -----Original Message-----
> From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf Of
> Jeffrey Hutzelman
> 
> On Wednesday, April 13, 2005 12:40:50 PM -0400 Kevin Coffman
> <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.)
> 
> Why not name them for the service principal?

Good idea!

> > I propose to add a new well-known key named "krb5_cc_active" to the
> > session-specific keyring which will hold the key serial number of the
> > 'active' credentials cache (keyring).  This will allow a user to change
> > KRB5CCNAME settings and create several ccaches as needed.  A utility
> > pgm will be required to change the 'active' key to point to the desired
> > active credentials cache.


> I'm a little confused here.  Presumably if I set KRB5CCNAME to
> "keyring:foo", then it should use the keyring named 'foo'.
> Under what circumstances does it use the keyring named in the
> krb5_cc_active key?

Our kernel/gssd interface for NFSv4 requests gss contexts on demand when the
kernel finds that it needs one, but doesn't have one.  The pre-keyring
implementation of gssd only gets a uid in the upcall, and we don't have the
user's environment variables to find it.  So it currently tries to figure
out which credentials cache to use to negotiate the context. (Making
assumptions of where the user's ccache might be stored in the filesystem.)  

In the new version, gssd will get more information and access to the user's
keyring, but will still not have access to the user's environment variables.
A user with more than one credentials cache in their (session or user)
keyring would have no way to direct gssd to the right credentials cache to
use.  So gssd will be able to read the krb5_cc_active key to determine where
the credentials cache is located.  The krb5_cc_active key will be set when a
new ccache is created.  If a user has only one, then they don't need to do
anything different.  If they want to switch between different ccaches, they
can set krb5_cc_active to point to the correct one.

The keyring ccache code will still get a name to locate the ccache.