On Dec 4, 2012, at 9:56 AM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> wrote: > On Mon, 2012-12-03 at 22:39 +0000, Adamson, Andy wrote: >> On Dec 3, 2012, at 4:06 PM, "Myklebust, Trond" <Trond.Myklebust@xxxxxxxxxx> >> wrote: > >>> It seems to me that this code allows me to kill anyone's rpcsec_gss >>> sessions by creating a key with their uid, and then destroying it. >> >> Yes - just proof of concept code. There is a lot to consider. >> >>> >>> One solution is to replace user_instantiate() with something that sets >>> the payload to a value determined by the kernel itself. We'd definitely >>> want to include the uid, but perhaps also add a cookie that is unique to >>> this key (using the idr/ida stuff from include/linux/idr.h ?), and that >>> can be used to distinguish it from keys generated from other processes. >>> If we were to use the same key to label the auth_gss creds, then we >>> could have user_gss_destroy() kill _only_ the auth_gss creds that it >>> spawned. >> >> Yes, killing only the auth it spawned is indeed what we want. >> >>> >>> Ultimately, though, I think we might want to let the user set at least >>> _part_ of the payload to something that might be useful to gssd when it >>> goes looking for credentials. Since the nfslogin and gssd will be >>> shipped as part of the nfs-utils package, it would be nice to allow them >>> to use the gss-ctx key in order to communicate. Interesting information >>> might include the KRB5CCNAME. >> >> Thanks for the good suggestions. > > So, I've got a question: Can we replace some of the stuff in the "RFC > Avoid expired credential keys for buffered writes" patch series with > this? > > My thinking is that since the user_gss_destroy() has to sync all files > and then invalidate the rpcsec_gss creds, we're pretty much doing the > same thing as in the above RFC patch series. I was thinking the other way 'round. When gss_user_destroy gets called due to nfslogout (kdestroy) it triggers the RPC avoid expiration on buffered writes code with one difference: It does not allow _any_ new writes or _any_ other RPCs to use a GSS context with a valid lifetime but to be destroyed due to logout. So instead of gss_user_destroy marking a GSS context as out of date, it will be marked as to be ONLY used for flushing writes that were buffered before the nfslogout (kdestroy) and associated commits. > If nfslogin were to tell > the gss-ctx key how long until the kerberos tgt expires, We already have an expired time for the TGT in the GSS context downcall. Why do we need nfslogin to repeat the information? If you want to have a work queue job wake up based on the TGT lifetime, the info is already in the GSS context. > couldn't we > have a work queue job wake up just before the tgt is about to expire, > and simply call user_gss_destroy by revoking the gss-ctx key? I think using the TGT lifetime that existed to at the creation of the GSS context trigger the RPC avoid cred expiration code works really well. I don't see a need for a workqueue thread. > If, on the other hand, the user renews the tgt using nfslogin, Yes - this is in plan. nfslogin (e.g. TGT renewal) will update an existing gss-ctx key which in turn will trigger an upcall on associated GSS contexts to have them renewed. I didn't want to bother with this until the idea of nfslogin/nfslogout had been flown :) > then we > could update the gss-ctx key, and defer the work queue job until the new > expirt time. With nfslogin updating the GSS context, the same will happen with the current RPC avoid expired cred code. -->Andy > > -- > Trond Myklebust > Linux NFS client maintainer > > NetApp > Trond.Myklebust@xxxxxxxxxx > www.netapp.com -- 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
