Real utility of idmapd

[J. Bruce Fields]

On Thu, Mar 22, 2007 at 11:08:45AM +0100, Guillaume Rousse wrote:
> J. Bruce Fields wrote:
> > The above is expected.  For example, if the client is stat'ing a file,
> > then the server must translate the uid and gid stored in the file's
> > inode into a string name that an NFSv4 client will understand.
> It works on the client, indeed: files owned by uid 501 on the server
> appears to be owned by user of the same name on the client, even if he
> has a different uid there (500).
> 
> My point it that on the server (stalingrad), file created from the
> client use wrong uid (501), instead of being correctly mapped to uid 500.
> 
> >From the rest of the discussion, I understand than with sys_auth and
> nsswitch mapping method, it is an expected failure

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.

It might be possible to create a new mechanism for doing that, but so
far it hasn't seemed worth the trouble.

--b.