On Dec 21, 2009, at 4:19 PM, Nicolas Williams wrote: > On Mon, Dec 21, 2009 at 02:57:25PM -0800, Bart Smaalders wrote: >> Tim Haley wrote: >>> I am sponsoring the following fast-track for Lisa Week. It >>> introduces >>> a new reserved uid and gid for purposes of improved ACL manipulation >>> when an id is not mappable by the client or server. Requested >>> binding >>> is patch/micro. Timeout is 1/6/2010. >>> >> >> Do the client and server exchange the unknown user id numerically or >> via a string? If a string, does fixing the userid matter, or is it >> the >> name that's important? > > I expect the answer to be "a string" in the NFSv4 case, qualified with > the sender's default domain (it has to have a domain qualifier).
That is correct. > > > Questions: > > - What about NFSv3? Will the NFSv3 server reject SETATTRs that refer > to UID/GID 96? Will the client send them? There are no changes to NFSv3 (or NFSv2) planned. > > > - The proposal says: > > |The client will map users or groups in an ACL that are unmappable to > |this newly reserved uid/gid. This reserved uid/gid will not be > allowed > |to be set in an ACL from the Solaris NFSv4 client. > > Will the NFS server ever send unknown@<server's default domain>? If > not, why not? The NFS server will send unknown@<server's default domain> only if the "unknown" uid or gid is stored in the ACL by the local file system. > > > Does the server enforce that unknown cannot be set by a client, or > does only the client enforce this? Only the client enforces this. If unknown@<domain> actually comes over the wire, the server will accept the ACL. The reason for this is to not expose the reserved uid/gid semantics to other clients (e.g. Linux) that don't care. The only id mapping related case where the server will fail the set ACL is when a user or group in the ACL can't be mapped to a valid user or group on the server. In this case, the server will send the NFS error NFS4ERR_BADOWNER to the client. This is what the Solaris server does today. > > > If the server enforces this, does it match unkn...@* or just > unknown@<server's default domain>? > > If the server matches unkn...@*, should this be standardized? > See above. The server will not enforce this. If it would, yes, unkn...@* should be standardized. Thanks, Lisa