Real utility of idmapd

[Guillaume Rousse]

J. Bruce Fields wrote:
> On Thu, Mar 22, 2007 at 11:02:12AM -0400, Kevin Coffman wrote:
>> On 3/22/07, Guillaume Rousse <Guillaume.Rousse at inria.fr> wrote:
>>> Kevin Coffman wrote:
>>>> On 3/22/07, Guillaume Rousse <Guillaume.Rousse at inria.fr> wrote:
>>>>> J. Bruce Fields wrote:
>>>>>>> >From the logs, the server seems to map ids on name, not names on id:
>>>>>>> Mar 20 15:33:52 stalingrad rpc.idmapd[19602]:  Server: (user) id "501"
>>>>>>> -> name "nobody"
>>>>>>> Mar 20 15:33:52 stalingrad rpc.idmapd[19602]: nfsdcb:
>>>>>>> authbuf=oberkampf.msr-inria.inria.fr authtype=group
>>>>>>> Mar 20 15:33:52 stalingrad rpc.idmapd[19602]:  Server: (group) id
>>>>> "501"
>>>>>>> -> name "nogroup"
>>>>>>>
>>>>>>> So name-based mapping appears to be working upside down here...
>>>>>> The above is expected.  For example, if the client is stat'ing a file,
>>>>>> then the server must translate the uid and gid stored in the file's
>>>>>> inode into a string name that an NFSv4 client will understand.
>>>>> It works on the client, indeed: files owned by uid 501 on the server
>>>>> appears to be owned by user of the same name on the client, even if he
>>>>> has a different uid there (500).
>>>>>
>>>>> My point it that on the server (stalingrad), file created from the
>>>>> client use wrong uid (501), instead of being correctly mapped to uid 500.
>>>> You claim the file is created with the "wrong uid" on the server.
>>>> Yet, an "ls -l" on that file on the server and on the client will
>>>> result in the same name, right?
>>> No. ls -l on the server attributes it to nobody, because uid 501 doesn't
>>> exist there. It should have been 500 if the mapping succedeed.
>> Then I am confused on where the 501 came from.
> 
> Suppose on the client we have:
> 
> 	on the client: bfields, uid 501
> 	on the server: bfields, uid 500 (and nobody has uid 501)
> 
> Then an auth_sys create creates a new file with uid 501, because the
> client sent its idea of bfields's uid to the server.
> 
> But if we stat the file on the client, the server will attempt to map
> 501, find nobody, and probably return something like
> 
> 	nobody at EXAMPLE.COM
> 
> So, you either need to use auth_gss instead of auth_sys, or modify the
> uid's to agree across the client and the server.
That's exactly the limitations I was attempting to isolate, thanks.