Re: numeric UIDs

[Tom Haynes <tdh@excfb.com>]

Chuck Lever wrote:
> On Aug 13, 2010, at 12:31 PM, J. Bruce Fields wrote:
>
>   
>> On Fri, Aug 13, 2010 at 10:43:06AM -0400, Steve Dickson wrote:
>>     
>>> On 08/11/2010 07:22 PM, Neil Brown wrote:
>>>       
>>>> I agree.  And surely it can all be solved in idmapd.
>>>>
>>>> On the server, tell idmapd to map all users to "NUMERIC_USER:%d" and all
>>>> groups to "NUMERIC_GROUP:%d" (or whatever) for some given clients (i.e. stop
>>>> ignoring the 'authentication name'.  And of course map those names back to
>>>> numbers.
>>>>
>>>> I don't know if the client can easily differentiate based on which server it
>>>> is talking to, but there is probably less need there (and maybe it can
>>>> anyway).
>>>>
>>>> It shouldn't take more that half an hour to hack something into
>>>> idmapd.c:nfsdcb() for the server side and nfscb for the client side - or
>>>> for a quicker hack, just go directly to imconv and ignore the client name on
>>>> the server.  (all this in nfs-utils of course).
>>>>         
>>> I took a look... and you are right it would not be that difficult to
>>> hack something up... but would this only be a Linux to Linux thing? 
>>> Or am I missing something?
>>>       
>> There are four cases where translation can be done:
>>
>> 	Sending id from server to client (ls, stat, getacl):
>> 		1. server uid -> string
>> 		2. string -> client uid
>> 	Sending id from client to server (chown, setacl):
>> 		3. client uid -> string
>> 		4. string -> client uid
>>
>> Cases 1 and 2 are uncontroversial.  Definitely map ascii-fied integers
>> in both of those cases.
>>
>> Case 4 violates the SHOULD on page 47.  Which would make case 3 useless
>> if all servers respect that SHOULD.  I think we should ignore the SHOULD
>> and implement 3 and 4 too, but Trond may not agree.
>>     
>
>   

So how would that happen?

If we send "2525" and we can locally map uid 2525 to 'bfields", does 
that mean the client is
attempting to subvert the normal process?

Or do we have to send uid 2525 to our id mapper to see if a reverse 
mapping applies?

What if there exists a thud@remote with that uid, but the mapping was 
really bfields@crimson?
We could claim it was a violation, which is why we would want the client 
to provide the
string and not the uid.


> Is this something that should be taken up in 3530bis?
>
>   

The issue should at least be presented on the working group alias.


>> I suppose we could make this all configurable, and then argue about what
>> the defaults should be.  If we implement all this in idmapd then that's
>> easy.
>>
>> I don't know what other clients and servers do.  Probably 1 and 2 at
>> least, but maybe it's something to check at the next bakeathon.
>>
>> Do we actually use an @-less "nobody" as suggested in the last
>> paragraph?  If not that might be something else to fix.
>>
>> --b.
>> --
>> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>     
>
> --
> Chuck Lever
> chuck[dot]lever[at]oracle[dot]com
>
>
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>