ccache using linux Keyrings
Wachdorf, Daniel R
drwachd at sandia.gov
Mon Apr 10 13:24:08 EDT 2006
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
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
(*) Each process subscribes to three keyrings: a thread-specific
process-specific keyring, and a session-specific keyring.
The thread-specific keyring is discarded from the child when any
clone, fork, vfork or execve occurs. A new keyring is created only
The process-specific keyring is replaced with an empty one in the
clone, fork, vfork unless CLONE_THREAD is supplied, in which case
shared. execve also discards the process's process keyring and
The session-specific keyring is persistent across clone, fork,
execve, even when the latter executes a set-UID or set-GID binary.
process can, however, replace its current session keyring with a
by using PR_JOIN_SESSION_KEYRING. It is permitted to request an
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
drwachd at sandia.gov
Sandia National Laboratories
Cyber Security Technologies
More information about the krbdev