On Tue, Aug 03, 2010 at 06:31:15PM -0400, Trond Myklebust wrote: > 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). Yeah, somebody should. > 2) Why is AUTH_SYS so sacrosanct? Because it's what almost everyone uses. > 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? Sure, that would be great. Again, that doesn't address the complaints above. --b. > 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. -- 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
