ccache using linux Keyrings

Wachdorf, Daniel R drwachd at
Thu Apr 13 23:13:01 EDT 2006

See Below:


From: Jeffrey Altman [mailto:jaltman at]
Sent: Thu 4/13/2006 4:35 PM
To: Wachdorf, Daniel R
Cc: krbdev at; Kevin Coffman; Machin, Glenn D
Subject: Re: ccache using linux Keyrings

I apologize for coming into this discussion a bit late but I would like
to better understand the problem you are attempting to solve.
It is theoretically possible for ccaches to be implemented at Global,
Session, Process, and Thread visibility levels.  Currently, the krb5 api
provides for Global, Session and Process visibility via the types:
FILE:, API:, and MEMORY:.  From the most simple minded approach
you could simply add three types KEYRING:, KEYRING_PROCESS:, and

It is important to me that we abstract out the functionality required
by the keyring specific implementation from that of the krb5 api.
For example, in order to add Thread visible ccaches to platforms without
keyrings I can imagine a trivial implementation of a TLS: (thread local
storage) version of the existing MEMORY: ccache type.

At the krb5 api level we need to be able to specify a per thread
default ccache name.  I don't think we need to try to morph a single
krb5_ccache type into all thread contexts.  Since the default ccache
name is maintained per krb5_context by allocating a krb5_context per
thread we already have the ability to obtain per-thread defaults.

Does the combination of per-thread krb5_context objects,
krb5_cc_set_default(), and distinct krb5_ccache types meet your
DAN: The problem arises when talking about NFSv4.  If you want to have per-thread authenticated NFSv4 access, then you need a per thread credential within the Kernel.  They keyring allows for a per thread storage mechanism that the Kernel could then use.  I think the big problem in the key-ring implementation is that you need a hint to give the kernel an idea of which credential cache to use, thus the need for the cc_active key in the keyring..

Jeffrey Altman

Wachdorf, Daniel R 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:

More information about the krbdev mailing list