Re: numeric UIDs

[Tom Haynes <tdh@excfb.com>]

J. Bruce Fields wrote:
> On Tue, Aug 17, 2010 at 12:46:09PM -0500, Tom Haynes wrote:
>   
>> Chuck Lever wrote:
>>     
>>> On Aug 13, 2010, at 12:31 PM, J. Bruce Fields wrote:
>>>       
>>>> 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?
>>     
>
> What's the antecedent to "that"?
>
>   

The SHOULD you quote:

   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.



>> 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?
>>     
>
> I don't understand what you mean by "subvert the normal process", nor
> what you see as the threat here.
>
>   

How do you detect the SHOULD?


>> Or do we have to send uid 2525 to our id mapper to see if a reverse
>> mapping applies?
>>     
>
> Checking for a reverse mapping doesn't sound like a good idea to me.
>
>   

No, it doesn't. My point is that the SHOULD is hard to enforce. How does 
the server
determine that there is a "valid translation"?


>> What if there exists a thud@remote with that uid, but the mapping
>> was really bfields@crimson?
>>     
>
> In the case of a user upgrading from NFSv3 to NFSv4, that's the behavior
> they've always had, so presumably they can live with it.  I'd prefer to
> avoid situations where something that previously worked over v3 fails
> when you upgrade the protocol version.
>
> I assume that most users arrive at NFSv4 by an upgrade from a previous
> version of NFS.
>
> So my priorities would be 1) to ensure the NFSv3->NFSv4 upgrade goes
> smoothly, then 2) to make it easy for users to switch from ids to
> strings, rather than forcing both at once.
>
>   

I'd say that problem breaks down to being able to correctly configure 
your id domain or to
allowing a server which is not connected to NIS/LDAP to be able to 
accept random users.
With NFSv3, a server will happily serve up data in these situations.

While various ways pop to mind to hack this up, why not bring it up to 
the working group
and get consensus? Perhaps whomever struck down Jim Rees will recall why 
it is such
a bad idea and convince us all to stay away from it. Or perhaps after 
years of enduring
customers who can't do the above, they will capitulate.