NFSv4 nobody issue

[Rick Macklem]

Loic Blot wrote:
> Hi,
> i tryed some other things
> 
> User nobody (65534)
> -> chown nobody /usr/jail/test.file => problem
> 
> Group nogroup (65533)
> -> chown :nogroup /usr/jail/test.file => same problem
> 
> Group nobody (65534)
> -> chown :nobody /usr/jail/test.file => no problem
> 
> Change user nobody UID from 65534 to 65533 => same problem. It's not
> a UID number problem but a name problem.
> 
Yes, for NFSv4 it is the names that go in the RPC request and not the
numbers. However, since there are the numbers in the AUTH_SYS credential
in the header (unless you are using Kerberized mounts), the numbers for
the names need to be consistent between client and server.

> Then, user nobody and group nogroup (not the integer values) are
> problematic. I looked at nfsuserd.c and i see:
> u_char *defaultuser = "nobody";
> u_char *defaultgroup = "nogroup";
> 
These are used if no mapping is found in the user or group database
for whatever name is in the RPC on the wire.

If you want to see what is happening, I suggest that you capture
packets when you do the "chown" (You can use "tcpdump -s 0 -w file.pcap host XXX".)
then look at them in wireshark.
In wireshark, look for the Setattr RPC and then look in the setable attributes.
You should find Owner which looks like "nobody@<your.dns.domain> and
Owner_group which looks the same (or "nogroup@<your.dns.domain>" if you
used nogroup). "nogroup" must be in your group database (/etc/group or whatever
you use for a group database) and the number must be consistent across client
and server.
Also, see what the reply to the Setattr RPC is (it is actually a Compound RPC
labelled "Setattr" for NFSv4).

If there is no Setattr RPC, then the mapping is failing in the client.

If the stuff looks correct on the wire, then it is most likely a server side
issue.

rick

> I think it's related.
> 
> Regards,
> 
> Loïc Blot,
> UNIX Systems, Network and Security Engineer
> http://www.unix-experience.fr
> 
> 13 octobre 2014 09:15 "Loïc Blot" <loic.blot at unix-experience.fr> a
> écrit:
> > Hi,
> > of course i have it. On each node:
> > 
> > # cat /etc/master.passwd | grep nobody
> > returns:
> > nobody:*:65534:65534::0:0:Unprivileged
> > user:/nonexistent:/usr/sbin/nologin
> > 
> > It's why i do a report here :)
> > 
> > Regards,
> > 
> > Loïc Blot,
> > UNIX Systems, Network and Security Engineer
> > http://www.unix-experience.fr
> > 
> > 10 octobre 2014 13:51 "Rick Macklem" <rmacklem at uoguelph.ca> a
> > écrit:
> > 
> >> Loic Blot wrote:
> >> 
> >>> Hello @freebsd-fs,
> >>> i'm trying to do jail hosting over NFSv4 with ezjail and i'm
> >>> experimenting an issue that i can't resolve. When i extract
> >>> base.txz (with ezjail) or i set nobody user on a file, i have
> >>> this
> >>> error:
> >>> 
> >>> chown nobody:nobody /usr/jails/fulljail/mnt/
> >>> No name and/or group mapping for uid,gid:(65534,65534)
> >>> chown: /usr/jails/fulljail/mnt/: Operation not permitted
> >>> 
> >>> No problem if i set:
> >>> chown mysql:nobody /usr/jails/fulljail/mnt/
> >>> 
> >>> Problem appears on all files.
> >> 
> >> Do you have a user by the name of "nobody" in your password
> >> database?
> >> (NFSv4 uses names and not numbers on the wire, so no name-->no
> >> mapping
> >> and chown can't be done.)
> >> 
> >> rick
> >> 
> >>> On my ZFS+NFSv4 server i do a dataset, exported in NFS
> >>> 
> >>> /etc/exports:
> >>> V4: /
> >>> 
> >>> zfs get sharenfs pool/jails:
> >>> -network=10.99.99.0 -mask=255.255.255.0 -maproot=root
> >>> 
> >>> nfsuserd and nfsv4_server_enable=YES on both client and server,
> >>> plus
> >>> nfsbcd on client.
> >>> 
> >>> On the client here is the fstab entry
> >>> 10.99.99.99:/pool/jails /usr/jails nfs rw,nfsv4 0 0
> >>> 
> >>> What i'm doing wrong ?
> >>> 
> >>> Thanks in advance
> >>> Regards,
> >>> 
> >>> Loïc Blot,
> >>> UNIX Systems, Network and Security Engineer
> >>> http://www.unix-experience.fr
> >>> _______________________________
> >>> 
> >>> freebsd-fs at freebsd.org mailing list
> >>> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> >>> To unsubscribe, send any mail to
> >>> "freebsd-fs-unsubscribe at freebsd.org"
> > 
> > _______________________________
> > 
> > freebsd-fs at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> > To unsubscribe, send any mail to
> > "freebsd-fs-unsubscribe at freebsd.org"
>