Real utility of idmapd

[the Edward Blevins]

On Thu, Mar 22, 2007 at 10:30:10AM -0400, J. Bruce Fields wrote:
> It has nothing to do with nsswitch--idmapd *only* deals with names that
> are used in the body of NFSv4 requests--in setattrs or getattrs that set
> or get the owner, owner_group, or acl attributes.  There simply is no
> kernel mechanism currently to allow us to map the credentials used in
> the rpc header when auth_sys is used.

I've been following along at home, but am still not entirely
clear on the limitations of a setup using auth_sys where uids are
not consistent between systems.

Here is what I've got so far, please let me know if I am missing
something.

Okay. NFSv4 deals in names, and not in uids. If I am using
auth_sys and browsing files on the server from a client, the uid
stored on the server is irrelevant. The server tells the client
that a file is owned by user at domain and then the client looks
up user at domain via idmapd. If the lookup successfully maps to a
local uid , then that uid is presented via the VFS.

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. However, the client appears to
be sending the uid (1002) across the wire without doing such a
translation, and the server then tries to map that uid to a name
local to itself. Based on my reading of the spec, this seems to
be allowed but discouraged (as is auth_sys it seems).

Based on reading through the list, and examining other resources
around the web, this seems to be currently expected behaviour.

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?

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