On Aug 1, 2013, at 3:05 PM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: > On Thu, Aug 01, 2013 at 03:24:05PM +0000, Adamson, Dros wrote: >> >> On Aug 1, 2013, at 10:56 AM, J. Bruce Fields <bfields@xxxxxxxxxxxx> wrote: >> >>> So the choices are: >>> 1. allow those problems, or >>> 2. change the nfs/krb5 security model from "once you give a >>> client your credential, you trust it with your data till the >>> credential expires" to "once you give a client your >>> credential, you trust it indefinitely". (Well, until its >>> state expires, anyway.) >>> >>> And we can implement either 1, or 2, or both, and if we implement both, >>> we get to choose which of 1 or 2 is the default. >>> >>> So I don't have a strong opinion yet, but I do fear that if we only >>> implement #2 there will be users who see that as a serious regression in >>> security. >> >> Perhaps you're right - the server is essentially trusting the client machine to do the right thing here, but the server is already trusting the client machine (not users) to do the right thing. A rouge client implementation could create all types of havoc as it stands now, i.e. using another user's credentials to bypass permissions, etc. > > Right, but normally that capacity for havoc is time-limited. For > example, you're not affected if a client is compromised after your creds > expire. > > I think that's pretty important. So let's make this optional. I'm > willing to argue about the default policy. > > Do all the operations that might conceivably be affected by this take > filehandles? If so an export option might make sense. Something like > > trust_client_writeback > > NFSv4.1 and higher clients who have accessed a file > using a user's credential will be permitted further > write access to that file using only their machine > credential. Some clients can take advantage of this to > write back cached data after user credentials expire, > preventing possible data loss in some cases. > > Maybe there's a better name! Making an option is fine with me. I think we'll eventually want it to be the default, but we'll still need a way to disable it. -dros > > --b. -- 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
