> -----Original Message----- > From: Trond Myklebust [mailto:Trond.Myklebust@xxxxxxxxxx] > Sent: Monday, November 29, 2010 3:26 PM > To: Spencer Shepler > Cc: Daniel.Muntz@xxxxxxx; spelic@xxxxxxxxxxxxx; linux-nfs@xxxxxxxxxxxxxxx > Subject: RE: NFSv4 behaviour on unknown users > > On Mon, 2010-11-29 at 18:16 -0500, Trond Myklebust wrote: > > On Mon, 2010-11-29 at 14:57 -0800, Spencer Shepler wrote: > > > Dan, > > > > > > A change to the NFSv4.0 and NFSv4.1 RFCs is unnecessary. > > > What you suggest can be implemented today and still adhere to the > > > RFC text. From RFC3530 (section 4.8) and RFC5661 (section 5.9) the > > > following text is quoted: > > > > > > " In the case where there is no translation available to the client > or > > > server, the attribute value will be constructed without the "@". > > > Therefore, the absence of the @ from the owner or owner_group > > > attribute signifies that no translation was available at the sender > > > and that the receiver of the attribute should not use that string > as > > > a basis for translation into its own internal format. Even though > > > the attribute value cannot be translated, it may still be useful. > In > > > the case of a client, the attribute string may be used for local > > > display of ownership. > > > > > > To provide a greater degree of compatibility with NFSv3, which > > > identified users and groups by 32-bit unsigned user identifiers and > > > group identifiers, owner and group strings that consist of decimal > > > numeric values with no leading zeros can be given a special > > > interpretation by clients and servers that choose to provide such > > > support. The receiver may treat such a user or group string as > > > representing the same user as would be represented by an NFSv3 uid > or > > > gid having the corresponding numeric value. A server is not > > > obligated to accept such a string, but may return an > NFS4ERR_BADOWNER > > > instead. 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." > > > > > > > > > I read this that if the implementation or administrator chooses to > > > op-out of the user@domain mapping, it may do so and the client and > > > server have a method available to them to communicate traditiona > > > uid/gid. > > > > > > So, all that is needed now it seems is some code to provide the > > > option to the admin or as you suggest, change the default. > > > > > > Spencer > > > > It is way too late to change the default. All known existing NFSv4 > > servers would spit at you because they have been coded to match the > > above normative "SHOULD". > > > > Without that option, you will also need a mechanism to allow the > > client and server to agree on a convention. Otherwise, admins have to > > go in and manually set the correct site default on all their clients and > servers. > > The other problem is that when you use the naked uid or gid you are losing > information about which domain the user belongs to. > > While that may be fine when you are authenticating using the AUTH_SYS > security flavour, it is just plain wrong when you are authenticating using > RPCSEC_GSS principals (which is what the NFSv4 spec assumes that you will > use). Then the administrator will not use that option. The use case that was presented did not use Kerberos (at least in my quick reading). I agree that users that use Kerberos will be unhappy and that they should use something that maps more in align with their Kerberos realms but that is not the pain point under discussion. A variation of the id mapping work under discussion by Andy would/could address Kerberos and other deployment scenarios. But for the original "works for NFSv3 and doesn't for NFSv4" crowd something simple will suffice and they will be happy and stop bitching about this and move onto the next thing that pisses them off. :-) Spencer > > -- > 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
