Hi all, I'm trying to understand the nuances of GSS security contexts with regards to NFSv4 with sec=krb5 under Linux. How does the in-kernel caching of these contexts work, i.e. what is the mechanism? And specifically, - How long do the in-kernel context caches live? - Is there any way to query the in-kernel context caches? - Is it possible for an individual user to have *multiple* in-kernel context caches? A simple example, for discussion: Say host "testhost" is an NFSv4 (sec=krb5p) client. In particular, the NFS mount is for user home directories. If I login to "testhost" and run "klist", I see I have two tickets, the TGT and the NFS service ticket for the home directory mount. Furthermore, my KRB5CC environment variable is set, and points to /tmp/krb5cc_uid_randomstring. So far, so good, no surprises. Now, if I delete the /tmp/krb5cc file, or run kdestroy, then run klist, it says "klist: No credentials cache found (ticket cache FILE:/tmp/krb5cc_uid_whatever)". Also not surprising. However, I still have access to my home directory. Now if I just do nothing on that terminal, and wait long enough, eventually I'll get "Permission Denied" on my home directory. That's somewhat surprising but readily explained by the in-kernel credentials cache. Also explicitly explained by the NFSv4 FAQ[1]: 6. I am accessing an NFSv4 mount via Kerberos and then I do a kdestroy, but I am still able to access the NFS data. Why? The kernel code caches the gssapi context that was negotiated using the Kerberos credentials. Destroying the credentials does not destroy the context in the kernel. We plan to change this behavior when moving to use the new key ring kernel support to store credentials and contexts. How long will this in-kernel context persist? I have tried to determine this experimentally, but it appears to be non-deterministic (or I haven't designed the right experiment). It almost seems like if you keep "using" the in-kernel context (e.g. continuously create and destroy random files on the Kerberized NFS share), that it lasts longer. (As opposed to just sitting idle at the terminal.) Likewise, let's say I have two separate ssh sessions into "testhost". In this case, I'll have two /tmp/krb5cc_uid_random files. Do I also have two separate in-kernel context caches, or just one? What happens if I run kdestroy on one terminal, but not the other? How does that affect the in-kernel cache(s)? [1] http://www.citi.umich.edu/projects/nfsv4/linux/faq/ Thanks, Matt -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
