On Wed, 2010-12-15 at 13:38 -0500, J. Bruce Fields wrote: > On Wed, Dec 15, 2010 at 01:22:13PM -0500, Trond Myklebust wrote: > > On Wed, 2010-12-15 at 13:08 -0500, J. Bruce Fields wrote: > > > On Tue, Dec 14, 2010 at 05:56:09PM -0800, Simon Kirby wrote: > > > > On Tue, Dec 14, 2010 at 05:10:21PM -0800, Simon Kirby wrote: > > > > > > > > > On Tue, Dec 14, 2010 at 03:38:43PM -0800, Simon Kirby wrote: > > > > > > > > > > > I'm just about to try > > > > > > 2.6.37-rc5-git3 on there plus your NFS fixes (which Linus seems to have > > > > > > half-merged and uploaded as -git3 but not pushed to his public git) > > > > > > > > > > Ignore this; I was just confusing myself by having the leak fixes already > > > > > applied. Otoh, I got this Oops while trying NFSv4. I'll check my > > > > > merging again. > > > > > > > > > > Do you have a git branch exposed with the "Allow the admin to turn off > > > > > NFSv4 uid/gid mapping" patches applied? > > > > > > > > Hm, the fixes were merged for -git4, and it seems to work fine there. > > > > > > > > As for the nfs4 uid/gid mapping patch, it seems the server side support > > > > for this is still neded? > > > > > > I'm not convinced that this behavior should depend on the security > > > flavor, so I'm assuming that something like steved's libnfsidmap patches > > > should do the job. > > > > Don't assume. > > > > Those patches do not fix the problem that if uid(name@server) != > > uid(name@client), then the client will be creating files with the 'wrong > > username' on the server. > > I don't see any obviously correct solution in cases where the mapping > disagrees between client and server sides, so prefer to stick to the > NFSv3 behavior. > > The only reason I see to do this anyway is to provide compatibility with > NFSv3. > > > In that case, everything from setuid applications through open(O_CREAT) > > to 'chown' will be broken because your authentication and authorisation > > models do not match up. > > Those are preexisting problems from NFSv3, and it's up to the > administrator to fix them. > > The best we can do is provide backwards-compatible behavior so that > things that worked before continue working. No. There are two cases here: 1) The user is authenticating using uids and gids (AUTH_SYS). In that case, the server is using those uids and gids to authorise user behaviour, and so file/directory creation/access/deletion/... will depend only on the numeric values of those uids and gids. It doesn't matter if the client belongs to a different domain, 'cos AUTH_SYS has no concept of a domain. It doesn't matter whether or mot there exists a name@domain mapping on the client, and server. Only the numbers matter. NFSv2 and NFSv3 got this case right, and NFSv4 got it wrong (or didn't consider it). 2) The user is authenticating using a principal name@DOMAIN. In this case, either there is a mapping between name@DOMAIN and a owner@domain +groupname@domain on the server, or there isn't. In the latter case, the server treats the principal as the anonymous user. In the former case, then if the client and server map owner@domain and groupname@domain to the same uid and gid, then it is safe to pass uids and gids back and forth. If they don't have identical mappings, then it is still safe to pass owner@domain and groupname@domain, but passing uids and gids is now wrong. NFSv4 gets this case right, but NFSv2/v3 get it wrong. Trond -- 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
