On Tue, 2010-08-03 at 18:23 -0400, J. Bruce Fields wrote: > On Tue, Aug 03, 2010 at 06:15:19PM -0400, Trond Myklebust wrote: > > On Tue, 2010-08-03 at 17:57 -0400, Jim Rees wrote: > > > Daniel.Muntz@xxxxxxx wrote: > > > > > > I'll fourth this motion. The spec goes out of its way to declare this a > > > violation. IMHO, the NFSv4.[0-n] specs should adopt the convention that a > > > uid string consisting of [0-9]+ be interpreted as the string > > > representation of a numeric UID--just as valid as a "user@domain" string. > > > > > > I argued for this as an option in the early days but was shouted down. > > > Sorry I can't remember the details, it was many years ago. > > > > Why is nobody talking about fixing AUTH_SYS? The alternative to using > > numeric uids/gids in NFS would be to use user@domain/group@domain in the > > credential. > > I'm not sure what that does to address complaints like original > poster's: > > http://marc.info/?l=linux-nfs&m=128080127215350&w=2 > > And I'd like it to be possible to make the NFSv3->NFSv4 upgrade as > transparent as possible. 1) RFC3530 does allow a workaround for cases where the _server_ doesn't have a mapping from uid/gid -> name. We just haven't implemented it on Linux servers (or clients). 2) Why is AUTH_SYS so sacrosanct? We know it has a bunch of problems, not least the one that limits ngroups <= 16, and the fact that it relies on uids (as opposed to login names) being the same on client and server so why not try to fix those limitations? 3) SECINFO can advertise a new auth mechanism without any problems. If done right, there would be no need to change default mount options on the client. Trond -- 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
