[CONFIGURATION] Strange behavior NFS 'root squash' and 'no root squash'

[richee]

Hi

I'm new to engaging with the Linux community in general although I've been using Linux on and off for a few years, so please forgive me if my etiquette is off or I have posted incorrectly, guidance is welcome.

I'm experiencing a strange issue with NFS and wonder if I have found a bug or if I'm missing something. I'm using Kubuntu 18.04 on the desktop and my Server is Ubuntu Server 18.04.

I'm trying to securely share some directories from the server to my desktop, I'll show the configuration I'm trying to achieve and the errors I get (the shares will not mount, access is denied) and the strange way in which I can get it working but not quite as secure as I would like.

Here's my /etc/exports file from the server

rich@server:~$ cat /etc/exports
/home/rich/unison-sync/Downloads 192.168.1.0/255.255.255.0(rw,sync,root_squash,subtree_check)
/home/rich/unison-sync/Music 192.168.1.0/255.255.255.0(rw,sync,root_squash,subtree_check)
/home/rich/unison-sync/Pictures 192.168.1.0/255.255.255.0(rw,sync,root_squash,subtree_check)
/home/rich/unison-sync/Videos 192.168.1.0/255.255.255.0(rw,sync,root_squash,subtree_check)
/home/rich/unison-sync/Documents 192.168.1.0/255.255.255.0(rw,sync,root_squash,subtree_check)
/var/www/rich 192.168.1.0/255.255.255.0(rw,sync,all_squash,subtree_check,ano nuid=33,anongid=33)

Here are the relevant entries from my /etc/fstab file on my kubuntu desktop

# nfs shares
192.168.1.42:/home/rich/unison-sync/Documents /home/rich/File-Server/Documents nfs rw,soft,intr,noatime,timeo=100,rsize=32768,wsize=3 2768 0 0
192.168.1.42:/home/rich/unison-sync/Downloads /home/rich/File-Server/Downloads nfs rw,soft,intr,noatime,timeo=100,rsize=32768,wsize=3 2768 0 0
192.168.1.42:/home/rich/unison-sync/Music /home/rich/File-Server/Music nfs rw,soft,intr,noatime,timeo=100,rsize=32768,wsize=3 2768 0 0
192.168.1.42:/home/rich/unison-sync/Pictures /home/rich/File-Server/Pictures nfs rw,soft,intr,noatime,timeo=100,rsize=32768,wsize=3 2768 0 0
192.168.1.42:/home/rich/unison-sync/Videos /home/rich/File-Server/Videos nfs rw,soft,intr,noatime,timeo=100,rsize=32768,wsize=3 2768 0 0
192.168.1.42:/var/www/rich /home/rich/File-Server/www_rich nfs rw,soft,intr,noatime,timeo=100,rsize=32768,wsize=3 2768 0 0

Here's the output when I try to mount

rich@kubu:~$ sudo mount -a
mount.nfs: access denied by server while mounting 192.168.1.42:/home/rich/unison-sync/Documents
mount.nfs: access denied by server while mounting 192.168.1.42:/home/rich/unison-sync/Downloads
mount.nfs: access denied by server while mounting 192.168.1.42:/home/rich/unison-sync/Music
mount.nfs: access denied by server while mounting 192.168.1.42:/home/rich/unison-sync/Pictures
mount.nfs: access denied by server while mounting 192.168.1.42:/home/rich/unison-sync/Videos

The issue preventing my mounting these shares are the options in the server /etc/exports file of "root_squash" which is what I am after. If I change this to "no_root_squash", the shares will mount, but as I understand it this is not properly secure.

Now here is the strange behavior (see modified /etc/exports file below), after changing only the first line in the /etc/exports file to "no_root_squash" on the server and then issuing the command "sudo exportfs -a" all shares will mount on the desktop and it all works without issue (except the security issue). I've now tested this several times and rebooted both desktop and server, several times and find this to be consistent.

/home/rich/unison-sync/Downloads 192.168.1.0/255.255.255.0(rw,sync,no_root_squash,subtree_check )
/home/rich/unison-sync/Music 192.168.1.0/255.255.255.0(rw,sync,root_squash,subtree_check)
/home/rich/unison-sync/Pictures 192.168.1.0/255.255.255.0(rw,sync,root_squash,subtree_check)
/home/rich/unison-sync/Videos 192.168.1.0/255.255.255.0(rw,sync,root_squash,subtree_check)
/home/rich/unison-sync/Documents 192.168.1.0/255.255.255.0(rw,sync,root_squash,subtree_check)
/var/www/rich 192.168.1.0/255.255.255.0(rw,sync,all_squash,subtree_check,ano nuid=33,anongid=33)

I've conducted a few experiments in trying to narrow things down further. I tried putting "no_root_squash" in another entry instead of the the one in the first line. This resulted in the original problem of access being denied.

I tried a different entry on the top line and various other things I now can't recall. It appears that I must have "no_root_squash" as an option in the first line of the exports file in order to be able to mount the entries. If all things were equal I would expect entries that contained the "no_root_squash" option to be the only shares mountable and the rest be denied. That is not the case. If the first entry has the option "no_root_squash", then all the entries below with "root_squash" as an option also mount.

This does not make sense to me, so I think I've either uncovered a bug, or there is something I do not understand. Ultimately I would like the system to work as expected using the "root_squash" option to ensure better security. The last entry in the exports file referring to "/var/www/rich/" contains my wordpress development environment files and has always worked as expected (interesting that the directory tree is outside /home, is that relevant?). I have tried "all_squash" and use the relevant "anonuid" and "anongid" for the user. The GID and UID numbers on the server and desktop are identical, but no dice there, just access denied, I find it all weird and inconsistent.

Please can anyone help and/or shed some light on what is going on here. Or should I report this as a bug, and if so, guidance on how to do this will be gratefully received.

Thankyou.

Richee

[sithlord48]

didn't make it all the way thru your post but

192.168.1.42:/home/rich/unison-sync/Documents /home/rich/File-Server/Documents nfs rw,soft,intr,noatime,timeo=100,rsize=32768,wsize=3 2768 0 0

Do you really have a space in the wsize value? That will cause it to not mount. wsize will be 3 and now some extra options are in this mount command and it fails.

There is an example of how i mount my NFS shares.

192.168.0.100:/mnt/data/archive /mnt/archive nfs4 _netdev,rw,noauto,user,intr,noatime 0 0

and its export on my server.

/mnt/data/archive 192.168.0.1/24(rw,sync,no_subtree_check)

your exports same to have a submask for what should be the ip range. (that might be a valid option also)

[oshunluvr]

Could be a NFSv3 vs. NFSv4 thing, but I'm unsure how "no_root_squash" is causing this or why you think that option makes your system more secure.

To discuss the use of these options;
By default, NFS automatically changes any files created by the root user to "nobody" user ownership. The "no_root_squash" option allows the root user to create and own files on the exported file system. In my view, this is a "file permission" issue not a "security" issue. In other words, using it doesn't make your system more secure, it only allows someone that already has root access to own a file. The file permissions you want to use should depend on the use of the target file system. Since you're exporting folder to a specific user's home, IMO the default option is preferred.

From Red Hat Customer portal:

5.4.3. Do Not Use the no_root_squash Option
By default, NFS shares change the root user to the nfsnobody user, an unprivileged user account. In this way, all root-created files are owned by nfsnobody, which prevents uploading of programs with the setuid bit set.
If no_root_squash is used, remote root users are able to change any file on the shared file system and leave trojaned applications for other users to inadvertently execute.

I use "all_squash" for shared (i.e. public) folders and leave the others as default.

I realize this doesn't directly solve your issue, but maybe removing no_root_squash is a better idea.