Strange behavior NFS 'root_squash' and 'no_root_squash' mount causes access denied

richee · 07-18-2018, 05:19 AM

Hi

I'm brand new to this forum, so please forgive me if I've posted incorrectly, any 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

Code:

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

Code:

# nfs shares
192.168.1.42:/home/rich/unison-sync/Documents /home/rich/File-Server/Documents nfsrw,soft,intr,noatime,timeo=100,rsize=32768,wsize=32768 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=32768 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=32768 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=32768 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=32768 0 0

Here's the output when I try to mount

Code:

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.

Code:

/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

berndbausch · 07-28-2018, 08:23 PM

Maybe it would help to enable logging on the server side. This seems to be non-trivial with NFS; I found a description at https://kerneltalks.com/config/nfs-logs-in-linux/.

I wonder if root squash is a red herring. Perhaps somehow your exports were not effective prior to running exportfs -a, and the problem gets resolved by exporting manually.

richee · 07-30-2018, 02:59 AM

It's the same on a server reboot and I've tried it several times so I don't think it's a red herring. Thanks for the link, I'll check it out and see if it helps.

hua · 08-03-2018, 09:02 AM

Maybe you need to add the NFS clients to hosts.allow. Depends on the Linux distribution but you can check if you have such files in /etc (hosts.allow hosts.deny)

http://nfs.sourceforge.net/nfs-howto/ar01s03.html

ondoho · 08-04-2018, 01:15 AM

this is how it is on my (debian) server:

Code:

$ cd /etc
$ cat exports 
/srv/nfs       nnn.nnn.n.nn(rw,async,fsid=root,crossmnt,subtree_check)
/srv/nfs/path1 nnn.nnn.n.nn(rw,async,no_subtree_check) 
/srv/nfs/path2 nnn.nnn.n.nn(rw,async,no_subtree_check)
$ cat fstab
/some/path1/					/srv/nfs/path1	none	bind 0 0
/another/path2					/srv/nfs/path2	none	bind 0 0

following some tutorial, i don't remember which.

it works.

if you use this only internally (as the ip suggests), i don't see any security issues.

also make sure it is not a firewall issue, on both sides.

richee · 08-05-2018, 05:07 AM

Quote:

Originally Posted by hua

Maybe you need to add the NFS clients to hosts.allow. Depends on the Linux distribution but you can check if you have such files in /etc (hosts.allow hosts.deny)

http://nfs.sourceforge.net/nfs-howto/ar01s03.html

Thanks for your suggestion hua, I have tried with the info from your link, it made no difference.

Quote:

Originally Posted by ondoho

this is how it is on my (debian) server:

Code:

$ cd /etc
$ cat exports 
/srv/nfs       nnn.nnn.n.nn(rw,async,fsid=root,crossmnt,subtree_check)
/srv/nfs/path1 nnn.nnn.n.nn(rw,async,no_subtree_check) 
/srv/nfs/path2 nnn.nnn.n.nn(rw,async,no_subtree_check)
$ cat fstab
/some/path1/					/srv/nfs/path1	none	bind 0 0
/another/path2					/srv/nfs/path2	none	bind 0 0

following some tutorial, i don't remember which.

it works.

if you use this only internally (as the ip suggests), i don't see any security issues.

also make sure it is not a firewall issue, on both sides.

Thanks ondoho. I'm not savvy enough to know if there are any security issues. It is all local, nothing here exposed to the internet, so I think I'll live with it as it is.

But is this issue a bug? To my (I admit limited) knowledge I think it is.

I tried a creative approach by adding the directory "null" in my home folder and adding this as the first line in /etc/exports

Code:

/home/rich/nul 192.168.100.100(rw,sync,no_root_squash,subtree_check),subtree_check)

with a non-existant ip address in the hope that having the first line in my exports file contain "no_root_squash" as an option would allow all the other directories to mount. No dice, it seems that the first line must be mounted "no_root_squash" to allow the rest of the mounts to work. I think there's mileage in this approach, but I don't have time to experiment right now.

One thing I forgot to mention, I did have this working as expected from the same machine running Manjaro a few weeks back, so maybe troubleshooting the client machine is a good idea. Beyond the /etc/fstab I don't know where to look.

I don't have access to another Linux Client right now, but I could load up a virtual machine and see where I get to with that.

Thanks again

Richee

ondoho · 08-06-2018, 01:58 AM

Quote:

Originally Posted by richee

Thanks ondoho. I'm not savvy enough to know if there are any security issues. It is all local, nothing here exposed to the internet, so I think I'll live with it as it is.

just to clarify, when i said "no security issues afaics", i was refering to my own solution.
you will notice that there's a confusing nested directory mount structure applied there. this is not my own invention but something i took from the tutorial i followed. i probably used the archwiki for this, even though my server runs debian.

Quote:

But is this issue a bug? To my (I admit limited) knowledge I think it is.

probably not.