NFSv4 nobody issue

Tue Oct 14 08:51:07 UTC 2014

Hi Rick,
thanks for your tip. It works perfect.
I think creating a sysctl variable must be fine to handle this precise case, no ?

I'll look at a patch today.

Regards,

Loïc Blot,
UNIX Systems, Network and Security Engineer
http://www.unix-experience.fr

13 octobre 2014 21:24 "Rick Macklem" <rmacklem at uoguelph.ca> a écrit: 
> 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"