On Tue, 2012-01-17 at 13:49 -0500, J. Bruce Fields wrote: > On Tue, Jan 17, 2012 at 12:24:44PM -0500, Jim Rees wrote: > > J. Bruce Fields wrote: > > > > On Tue, Jan 17, 2012 at 11:31:33AM -0500, Jim Rees wrote: > > > Sachin Prabhu wrote: > > > > > > On Tue, 2012-01-17 at 08:49 -0500, Jim Rees wrote: > > > > Sachin Prabhu wrote: > > > > > > > > We had a user report that for an export shared with sec=krb5*, any > > > > changes in user credentials(ex: add user to a secondary group) take some > > > > time before they take effect over the NFS share. > > > > > > > > Re-authenticating, either by removing the service ticket or by re-running > > > > kinit at the client, should also flush the old credentials. Can you confirm > > > > that works? > > > > > > We have tried it but it doesn't work unless you actually clean up the > > > cache on the NFS server with the command > > > echo `date +'%s'` > /proc/net/rpc/auth.rpcsec.context/flush > > > > > > Bruce, shouldn't this work? Is this a bug or a feature? > > > > kdestroy, kinit, etc. on the client only affect userspace; the NFS > > client in the kernel continues to use the same gss context. > > > > I would find it surprising if kdestroy didn't actually discard my > > credentials. In fact I might even view this as a security risk. > > Volunteers to fix this are welcomed.... I think this might be part of > the project Simo Sorce is working on, but I'm not sure. I have tested by setting a timeout on the the client side rpc.gssd. Using kdestroy-kinit, I was able to get a new kerberos ticket and subsequently force the NFS server to obtain new credentials for the user. I do agree with Jim Rees that this is a security issue. The user can use kdestroy to destroy credentials before logging out. However the credentials cached in the kernel will allow the user to continue accessing the NFS share for as long as the cache is valid. Sachin Prabhu -- 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
