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

Reply via email to