kerberos keyring ccache

[Steve French]

Luke Howard wrote:

>Hi Steve,
>
>
>>3) if ticket is expired, refresh the service ticket
>>    
>>
>
>We discussed using /sbin/request-key to do this but given the keyring
>ccache type is a "user" keyring, I think the consensus is to do this
>in a (ccache-type agnostic) daemon.
>
>cf. ktkt_warnd in Solaris 10, where pam_krb5/kinit registers the
>principal and ticket expiry time with the warn daemon, and the warn
>daemon renews tickets.
>  
>
IIRC on OS/2 a daemon in userspace started trying to refresh Kerberos 
service tickets needed by the
network filesystem client well before they expired (perhaps starting at 
1/2 ticket expiration time).

>>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
>>    
>>
>
>Worth looking at what NFSv4 does today with gssd, and what it might do
>tomorrow with a GSS context keyring type.
>  
>
Yes - my guess is that there are a few network cases (not just cifs, 
nfs) where the problems are identical
(not just mapping uid -> user at realm and vice versa)

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

> 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).