ccache using linux Keyrings

[Jeffrey Altman]

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
KEYRING_THREAD:.

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
needs?

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: