Tom Haynes said: > > While various ways pop to mind to hack this up, why not bring it up > > to the working group and get consensus? Perhaps whomever struck down > > Jim Rees will recall why it is such a bad idea and convince us all > > to stay away from it. Or perhaps after years of enduring customers > > who can't do the above, they will capitulate. Adding nfsv4 list to the cc. So, to summarize: every now and then somebody asks why the Linux NFSv4 implementation doesn't allow (ascii-encoded) numerical uid's and gid's; most recently: > On Tue, Aug 03, 2010 at 04:01:32AM +0200, Victor Mataré wrote: >> I still hope I'm mistaken in assuming I have to go back to NFSv3 if I >> want to skip NFSv4 UID mapping altogether and just use the numeric >> UIDs the way they're stored on-disk.... They went on to describe a situation (apparently hypothetical) where NFS is used to perform backups of a filesystem when the server storing the backup (and maybe even the client performing the backup) lack mappings referred to by the filesystem. This is a use case that would work over v3 but likely not v4, as v4 implementors are advised against allowing this on page 47 of rfc 3530: > > To avoid this mechanism being used to subvert user and > > group translation, so that a client might pass all of the owners and > > groups in numeric form, a server SHOULD return an NFS4ERR_BADOWNER > > error when there is a valid translation for the user or owner > > designated in this way. In that case, the client must use the > > appropriate name@domain string and not the special form for > > compatibility. String uid's have advantages, but I've been arguing that: > > >In the case of a user upgrading from NFSv3 to NFSv4, that's the behavior > > >they've always had, so presumably they can live with it. I'd prefer to > > >avoid situations where something that previously worked over v3 fails > > >when you upgrade the protocol version. > > > > > >I assume that most users arrive at NFSv4 by an upgrade from a previous > > >version of NFS. > > > > > >So my priorities would be 1) to ensure the NFSv3->NFSv4 upgrade goes > > >smoothly, then 2) to make it easy for users to switch from ids to > > >strings, rather than forcing both at once. So the question is whether there's still consensus for that SHOULD. As Tom says: > > I'd say that problem breaks down to being able to correctly > > configure your id domain or to allowing a server which is not > > connected to NIS/LDAP to be able to accept random users. With > > NFSv3, a server will happily serve up data in these situations. So I suppose it comes down in part to a question of whether users of the various implementations have actually seen these problems in practice and, if so, whether diagnosing the problem, and setting up the required mapping, has been an obstacle to NFSv4 adoption. --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
