On Wed, 2010-08-18 at 15:09 -0400, Steve Dickson wrote: > > On 08/18/2010 02:20 PM, J. Bruce Fields wrote: > > On Tue, Aug 17, 2010 at 03:38:43PM -0400, Steve Dickson wrote: > >> In recent NFS v2/v3 to v4 transitions, one of the sticking > >> points have been that fact v4 uses strings in the format > >> of "user@domain" instead of 32bit integers for uids and > >> gids. > >> > >> When the string can not be mapped, its mapped to the 'nobody' > >> user which is not optimal for things like backup servers and > >> such where the ids will not be know by both sides. > >> > >> So this patch series enables the server to send out numeric > >> string of uids and gids that do not have the '@domain' part. > >> The series also adds functionality to the client that parse these > >> type of strings and will use the numeric representation > >> of the ids iff the id exists on the client, which is > >> sightly different that Solaris. Solaris dose not have that > >> "id must exist" restriction. > > > > Why did you decide to impose that restriction? > I just thought it made sense, from a security standpoint to make sure the > ids were at least valid on the client... if they are not valid the id > becomes 'nobody' which how it works today... but is different than how > OpenSolaris does it... they just use whatever the server tells to... As I read RFC3530, the recommendation is that the server SHOULD reject an attempt by the client to use numeric ids if it knows of a valid name@domain mapping for that uid or gid. The client has no such restriction. It probably should just accept the numeric uid or gid if that is what the server supplies. Cheers 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
