Real utility of idmapd

[William A. (Andy) Adamson]

On 3/20/07, Guillaume Rousse <Guillaume.Rousse at inria.fr> wrote:
>
> William A. (Andy) Adamson wrote:
> >
> >
> > On 3/20/07, *Guillaume Rousse* <Guillaume.Rousse at inria.fr
> > <mailto:Guillaume.Rousse at inria.fr>> wrote:
> >
> >     Hello.
> >
> >     This may seems a naive question, but I'm still trying to figure
> where id
> >     mapping is really needed, even after reading
> >
> http://www.citi.umich.edu/projects/nfsv4/crossrealm/libnfsidmap_config.html
> ,
> >     and trying myself.
> >
> >     If I understand correctly:
> >     - nfs-independant nss mapping is needed anyway for operations as ls
> on
> >     client side, to display correctly names instead of uid
> >
> >
> >
> > That is NFSv3. NFSv4 places names, not UID or GID on the wire - look at
> > the GETATTR/SETATTR owner, owner_group and ACLs.
> Well, I'm just quoting
>
> http://www.citi.umich.edu/projects/nfsv4/crossrealm/libnfsidmap_config.html
> ,
> here "Commands such as ls still use the nsswitch infrastructure."
>
> However, you're right, I missed it in my tests: all files belonging to
> an user on server appears to belong to the same user on client if they
> also exist, even with different uid, otherwise they are listed as
> belonging to nobody, as configured in idmapd.conf
>
> So name-based mapping appears to work here.
>
> BTW, I know what ACLs are, but not what are GETATTR/SETATTR owner and
> owner_group, sorry :(


read the NFSv4 spec.

>     - with auth_sys, file operations such as open, close, etc.. depends on
> >     user uid, needing them to be identical on both side: again,
> >     nfs-independant nss mapping is needed. And properly-configured
> idmapd
> >     seems to be useless.
> File created on client appears to be owned by the client uid on the
> server,


yeah, and in NFSv4 the UID had to be mapped from the name on the wire.

which lead to my initial claim. If ACLs are activated, those
> files are undeletable, but without they are not.