Re: numeric UIDs

["J. Bruce Fields" <bfields@fieldses.org>]

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.

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.