If I have more than one V3 entry in /etc/exports with the same hostname, mountd is spitting out the following error on /dev/console with the default syslog.conf, for example: % service mountd reload mountd: can't change attributes for /tmp/bar: Invalid radix node head, rn: 0 0xfffff80035180300 % showmount -e Exports list on localhost: /scratch 192.168.137.0 /tmp/foo localhost % ls /mnt/hello_world ls: /mnt/hello_world: No such file or directory % touch /tmp/bar/hello_world % ls /mnt/hello_world /mnt/hello_world % umount /mnt % uname -a FreeBSD freebsd-10-x64.localdomain 10.0-STABLE FreeBSD 10.0-STABLE #0 7905925(stable/10): Wed Jun 11 14:10:17 PDT 2014 root@freebsd-x86.localdomain:/usr/obj/usr/src/sys/GENERIC-WITHOUT-WITNESS amd64 % As shown above, /tmp/bar doesn't show up via showmount -e for the list of exports but the path is mountable and I created /tmp/hello_world, and it appeared in the mount location as expected because the path was mounted. This issue occurs on vanilla FreeBSD 10-STABLE and 11-CURRENT. Reproduction steps: mkdir /tmp/foo /tmp/bar cat > /etc/exports <<EOF /tmp/bar -alldirs localhost /tmp/foo -alldirs localhost EOF cat > /etc/rc.conf.local <<EOF mountd_enable="YES" nfs_server_enable="YES" EOF service nfsd start service mountd start Expected Result: - showmount -e should show the list of exported paths. /tmp/bar and /tmp/foo should be exported. - Both paths should be mountable.
The security team might want to audit this to ensure that this isn't a security vulnerability.
Exporting subdirectories of a mountpoint is problematic and this is a well known limitation of the protocol. I don't consider this as a security issue because the administrator is supposed to know what they are doing.
(In reply to yaneurabeya from comment #0) ... > As shown above, /tmp/bar doesn't show up via showmount -e for the list of > exports but the path is mountable and I created /tmp/hello_world, and it This should have been "/tmp/bar/hello_world" (In reply to Xin LI from comment #2) > Exporting subdirectories of a mountpoint is problematic and this is a well > known limitation of the protocol. I don't consider this as a security issue > because the administrator is supposed to know what they are doing. The security concern was over the fact that mountd is clearly reporting an error in the code, but hiding the fact that it's actually an error; unless the administrator is looking for errors from mountd, they have absolutely _no_ idea that the path is actually exported.
(In reply to yaneurabeya from comment #3) > (In reply to Xin LI from comment #2) > > Exporting subdirectories of a mountpoint is problematic and this is a well > > known limitation of the protocol. I don't consider this as a security issue > > because the administrator is supposed to know what they are doing. > > The security concern was over the fact that mountd is clearly reporting an > error in the code, but hiding the fact that it's actually an error; unless > the administrator is looking for errors from mountd, they have absolutely > _no_ idea that the path is actually exported. mountd have (correctly) reported that it was unable to change the export attributes, we could, of course, use better error message, but if the administrator chooses to ignore error messages, there is nothing we can do with it. Also, exporting subdirectories just plain doesn't work because the NFS client can still request anything in the mountpoint. Properly implemented client does not allow it but an attacker do not have to use a properly implemented one. This is well known and relying on this security model is just plain wrong.
(In reply to Xin LI from comment #4) > (In reply to yaneurabeya from comment #3) > > (In reply to Xin LI from comment #2) > > > Exporting subdirectories of a mountpoint is problematic and this is a well > > > known limitation of the protocol. I don't consider this as a security issue > > > because the administrator is supposed to know what they are doing. > > > > The security concern was over the fact that mountd is clearly reporting an > > error in the code, but hiding the fact that it's actually an error; unless > > the administrator is looking for errors from mountd, they have absolutely > > _no_ idea that the path is actually exported. > > mountd have (correctly) reported that it was unable to change the export > attributes, we could, of course, use better error message, but if the > administrator chooses to ignore error messages, there is nothing we can do > with it. > > Also, exporting subdirectories just plain doesn't work because the NFS > client can still request anything in the mountpoint. Properly implemented > client does not allow it but an attacker do not have to use a properly > implemented one. This is well known and relying on this security model is > just plain wrong. I forgot to include the fact that localhost:/tmp/bar was mounted to /mnt ; this was implied in my reproduction steps. /tmp/foo and /tmp/bar are two distinct paths. Why is /tmp/foo being exported if it's not showing up in showmount -e? Yes, I know that I've been playing in Linux for a little too long (9 months), and looking back I'm not using the prescribed syntax for exports(5), but I expected the code to not export /tmp/bar and it did. (posing the question differently) As a sysadmin/support engineer, how could I understand that mountd has actually exported the directory if the tools that should be doing this (showmount -e) don't print out anything meaningful?
If you read exports(5) there is some confusingly worded instruction on this point What you actually want to do to export those 2 subdirectories is: /tmp/bar /tmp/foo -alldirs localhost However, the "security" is only enforced by mountd, not the nfs daemon, so you should consider that.