[Keyrings] Re: kerberos keyring ccache

[Kevin Coffman]

On 1/23/06, Steve French <smfltc at us.ibm.com> wrote:
> This discussion on using the infrastructure for caching kerberos tickets
> sounds promising, but I am missing some background information on what
> has been added.   Are there pointers to background information on the topic?
>
> The needs for cifs client (and presumably non-kernel samba client code
> eventually) would be:
> 1) identify whether current (perhaps current->fsuid) already has a krb5
> service ticket for a particular server/service
> 2) if no service ticket, request a service ticket for current
> 3) if ticket is expired, refresh the service ticket
> 4) upcall to samba tooling (similar to Samba's ntlm_auth used by some
> apache modules etc.) to SPNEGO authenticate with that ticket if SMB/CIFS
> session is not authenticated
>
> Parts of the first three items seem like they relate to the earlier
> discussion thread - but I am not sure where to look to get up to speed
> on what has been done already for the somewhat similar cases for nfsv4
> and afs on the first three items

Maybe I should explain how NFSv4 plans to use the keyring to store
gssapi context keys and how we leverage the keyring implementation of
the Kerberos ccache for this.

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.  (Not
necessarily Kerberos mechanism contexts.)  Even though the kernel
knows what GSS mechanism it needs a context for, it cannot negotiate a
new gss context anyway.  Therefore, it never bothers to look to see
what Kerberos tickets might be cached in the keyring.

If the NFSv4 kernel client code notices that it has either no
rpcsec_gss_context, or an expired context, it does an upcall to the
userland gssd daemon to negotiate the rpcsec_gss context with the
NFSv4 server.  (Actually, the NFSv4 code just asks the keyring
facility for the key, and either gets it or key-request is invoked to
try and instantiate it.) In the keyring version, gssd will instantiate
the rpcsec_gss_context key and the NFSv4 kernel code is happy.

The reason we wanted Kerberos credentials in the keyring was so that
gssd doesn't have to go blindly rummaging through the filesystem to
try and find the "right" credentials cache to use in negotiating the
gss context for a given process.  (gssd does not get env. variable
information from the user process that caused the upcall.)

Given our needs, my current implementation of the keyring Kerberos
Credentials Cache is totally written in user space using only "user"
keys.  It sounds like others may have a need for a kernel
implementation of a "kerberos" key type, or at least have some special
needs for querying what kerberos "user" keys are stored in the kernel,
from within the kernel?

K.C.