ccache using linux Keyrings

[Jeffrey Altman]

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

There is an assumption being made that a thread has a single credential
cache and in the krb5 api the association is not between a thread or a
process and a credential cache but between a krb5_context and a
credential cache.

The krb5_context does not have to be used only by one thread.  The
requirement is that a krb5_context never be used by more than one thread
at the same time.  The krb5_context might be associated with a user
and is re-used by different threads at different times as in a
connection pool.  From the perspective of the krb5 api this model is
completely rational.

The existing usage models are not compatible with a file system or
device driver that needs access not simply to a credential cache
but to *the* security context associated with the thread either
through direct assignment or inheritance from the process or security
session.  The conflict between the two models is that the krb5 api
allows a many to many association of krb5_context and threads.  Whereas
the requirements of a file system or driver are a one to one association
of krb5_context to thread.  But its not even that clean as a thread
that doesn't have its own krb5_context must receive a read only
clone of the process krb5_context when it transitions into kernel space
in order to ensure the state does not become altered while the kernel
operations are in progress.

As such, I believe that what you need to store for the thread is not
a 'cc_active_key' but in fact a krb5_context that is used for all krb5
operations performed on behalf of the thread once the kernel boundary
is crossed.  This would be a major change in usage of the krb5 api
but would (I believe) produce a much saner usage model in the long term.

Jeffrey Altman