Real utility of idmapd

[the Edward Blevins]

On Sun, Mar 25, 2007 at 11:04:40AM -0400, J. Bruce Fields wrote:
> On Sun, Mar 25, 2007 at 02:45:36AM -0500, the Edward Blevins wrote:
> > So far all is well. Then I try and create a file as user
> > (uid=1002) on my local system; What I would expect to happen is
> > for the client to consult with idmapd in order to discover the
> > name associated with uid=1002 (user), then send that across the
> > wire as the creator of the file.
> 
> Nope.  There's two layers at work here--NFSv4 operates on top of RPC.
> The NFSv4 layer itself only deals in names, but the server's notion of
> who performs a given operation (like file creation) is not determined by
> looking at anything in the NFSv4 operation--it's determined by looking
> at the credential field in the RPC header.  The auth_sys credential
> contains only uid's.

Brilliant. This all makes sense now. I was missing the critical distinction
between the RPC credentials and the NFSv4 names.

> > Here is my question: Is there is some good technical reason the
> > client can't do a uid->name lookup before sending the request
> > across the wire, or is it just a feature that no one has bothered
> > implementing?
> 
> So in the auth_sys case if you wanted to handle clients and gid's with
> different user<->uid mappings, you'd need to add auth_sys uid<->uid
> mapping mechanisms on client and/or server.  We don't have anything like
> that currently.

I see how one could build a layer where the server asked the client to map
the uid back to a name, but the deeper I dig into this the more I understand
why that hasn't been done. 

Perhaps it is time for me to start playing with krb5 again.

Thanks. :)

-- 
the Edward Blevins   <thedward at barsoom.net>    (512) 796-6661
Today is Prickle-Prickle, the 11st day of Discord in the YOLD 3173