ccache using linux Keyrings

[Kevin Coffman]

You can find the code Dan is talking about at:
http://www.citi.umich.edu/projects/nfsv4/linux/keyring/

I think that having three alias ccache types such as KRTHREAD:,
KRPROCESS:, and KRSESSION is another possible way of expressing which
keyring to associate the credentials.

K.C.

On 4/10/06, Wachdorf, Daniel R <drwachd at sandia.gov> wrote:
>
>
> 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
>
>