kerberos keyring ccache

[Kevin Coffman]

On 1/23/06, Steve French <smfltc at us.ibm.com> wrote:

> > The NFSv4 client kernel code does not care about Kerberos tickets or
> > what Kerberos tickets a user may have stored in the kernel keyring
> > facility.  What it needs are negotiated rpcsec_gss contexts.
> This is somewhat similar for cifs - we need an authenticated
> context - typically achieved by encapsulating Kerberos tickets (or even
> in the old days an NTLM password) via SPNEGO (IIRC this is basically RFC 2478
> but opaque to my code if user space utilities such as the misnamed "ntlm_auth"
> utility or equivalent hide this) but in theory this could be something other
> than Kerberos, perhaps x509 even though not seen often in the wild yet.

So your steps 1-3 in the kernel code looking for Kerberos tickets and
their expiration is just a shortcut to possibly skip the upcall?

> > If the NFSv4 kernel client code notices that it has either no
> > rpcsec_gss_context, or an expired context, it does an upcall to
>
> This is something I would like to understand - I have assumed that NFSv4
> client code has a very similar need here - how can you (NFS client) tell
> from something hanging off the current task struct enough information to know
> who the user is (and therefore check if you have an authenticated context
> for them) without simply using the uid (which seems insufficient since
> it could presumably match to more than one security context).

Exactly.  The current (pre-keyring) upcall gets only a uid as input. 
That is related to my statement of "blindly rummaging through the
filesystem" to find the right credentials to use to create the
context.

With the keyring code, we get a bit more information.  Most
importantly, we get the instigating process's keyring information.  So
we can do a focused search looking for Kerberos (or PKI) credentials
to use to create the context.  With David's latest patches (which
AFAIK are still not in the mainline kernel?) the search of the
original process's keyrings comes automatically after the userland
process call to keyctl_assume_authority().

Trond's original patch to use the keyring code for the
rpcsec_gss_context keys was in our CITI_NFS4_ALL kernel patch for a
short time, but is not in current versions.  If you'd like to see that
and how it works, let me know.