[Keyrings] Re: kerberos keyring ccache

[Steve French]

Kevin Coffman wrote:

>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?
>
>  
>
Yes - on path based calls (open/create/mknod/mkdir etc.) it is essential 
to use the right
"smb uid" (which was returned on smb/cifs session setup when a security 
context for
 the authenticated user is successfully established) and if there is no 
authenticated session
for this local security context (which could be more than a uid) - I 
need to upcall.
It would be a complete disaster (bad performance) to upcall very often - 
I am hoping
that nfs (and afs and others) that care about kerberos like cifs - can 
recognize
security credentials that are set by winbind (the pam/nss logon code) or 
pam_kerberos
at logon time and save them in the credential cache.   What I am not 
clear on is
how to look at the krb5 tickets for the process (that in an ideal case 
winbind or pam_kerberos
set at logon time) just enough to tell whether I have already 
authenticated that user.  


>>>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.
>
>  
>
I agree that the uid alone is insufficient  (most MS kerberos tickets 
include pacs with
group memberships and that may not map one to one to local uids).

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

Yes - I am interested in seeing that.   Thanks.

Maybe part of what I am missing is whether the winbind module (for 
setting the security information in the kernel keyring for the case
of kerberos authentication to Windows or XAD or whatever krb5 kdc) or 
pam_krb5 even are aware of the kernel keyring at all.
It would be awful to have to run a command line utility after logon to 
set your kerberos credentials