ccache using linux Keyrings

[Wachdorf, Daniel R]

I have been testing out Kevin Coffman's implementation of the Linux
Keyring credential cache (previously discussed on the list) and had a
few suggestions for changes:

Currently, all credentials live in the session keyring.  By default, the
code creates a session keyring called /tmp/krb5cc_UID.  He also creates
a key within the session keyring called krb5_cc_active - which contains
the name of the "active" session keyring.  You can specify an
environmental variable to specify a different keyring which to use
(takes higher priority then the krb5_cc_active).  The environmental
variable is specified KEYRING:NAME where NAME is the keyring name (for
example KRB5CCNAME=KEYRING:/tmp/krb5cc_1234).  

Given the way the code is implemented, krb5_cc_active always points to
the last keyring cache created (cc_resolve called with a not yet
existing keyring name).  (There is a slight issue here in terms of
default credential cache changing when I call cc_resolve with a
different keyring name - but that's another discussion).

The linux keyring implementation supports 3 keyrings (from the kernel
docs):

(*) Each process subscribes to three keyrings: a thread-specific
keyring, a
     process-specific keyring, and a session-specific keyring.

     The thread-specific keyring is discarded from the child when any
sort of
     clone, fork, vfork or execve occurs. A new keyring is created only
when
     required.

     The process-specific keyring is replaced with an empty one in the
child on
     clone, fork, vfork unless CLONE_THREAD is supplied, in which case
it is
     shared. execve also discards the process's process keyring and
creates a
     new one.

     The session-specific keyring is persistent across clone, fork,
vfork and
     execve, even when the latter executes a set-UID or set-GID binary.
A
     process can, however, replace its current session keyring with a
new one
     by using PR_JOIN_SESSION_KEYRING. It is permitted to request an
anonymous
     new one, or to attempt to create or join one of a specific name.

I was thinking that it would be preferable to use the environmental
variable to specify which keyring the credentials cache code would use.
Thus, you could specify the "level" at which your credentials cache
exists by setting the environmental variable (KRB5CCNAME=KEYRING:thread
or KEYRING:process, ect).  

The krb5_cc_active (or probably an environmental variable like
KEYRING_KRB5CC_ID) key could still be used to control which keyring is
actually used as the credentials cache, but it would only apply to the
level keyring.

-------------------------------------- 
Daniel Wachdorf 
drwachd at sandia.gov 
Sandia National Laboratories 
Cyber Security Technologies 
505-284-8060