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