Real utility of idmapd

[J. Bruce Fields]

On Sun, Mar 25, 2007 at 02:45:36AM -0500, the Edward Blevins wrote:
> 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.

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.

The krb5 case is a bit more complicated, but basically what the server
ends up with is a krb5 principal, which it has to map somehow to a
local uid (but that's done by rpc.svcgssd in our implementation, not by
rpc.idmapd).

> 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.

--b.