NFSv4 nobody issue

Mon Oct 13 19:24:43 UTC 2014

Loic Blot wrote:
> Hi Rick,
> no request is done.
> In /var/log/messages on the client i have:
> 
> Oct 13 15:10:46 machine kernel: No name and/or group mapping for
> uid,gid:(65534,-1)
> 
> The FreeBSD kernel refuses to change the owner.
> 
Ok, I took a look and it is a restriction enforced by the server.
If you want it to work, you need to comment out these lines in
sys/fs/nfsserver/nfs_nfsdsubs.c:
if ((NFSVNO_ISSETUID(nvap) && nvap->na_uid == nfsrv_defaultuid)
1547 	|| (NFSVNO_ISSETGID(nvap) && nvap->na_gid == nfsrv_defaultgid)) {
1548 	error = NFSERR_BADOWNER;
1549 	goto out;
1550 	}
(Line#s 1546->1550 in head.)

It is done because some clients try to set the owner when there is no
valid mapping by sending "nobody@<your.dns.domain>" to the server.
Unfortunately for you "nobody" is the traditional name for "no mapping".
For example, if "chown rick <file>" was done on a client where "rick"
is not in the client's passwd database, some clients will send "nobody@<your.dns.domain>"
and the above code makes sure that doesn't work.

So, if you want this to work, comment out the above lines in your NFSv4 server's
kernel.

rick

> Regards,
> 
> Loïc Blot,
> UNIX Systems, Network and Security Engineer
> http://www.unix-experience.fr
> 
> 13 octobre 2014 14:43 "Rick Macklem" <rmacklem at uoguelph.ca> a écrit:
> > 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"
> 