Bug 191218 - mountd: can't change attributes for XXXXXXX: Invalid radix node head, rn: 0 0xXXXXXXXXXXXXXXX; can still mount path
Summary: mountd: can't change attributes for XXXXXXX: Invalid radix node head, rn: 0 0...
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: 10.0-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-06-20 18:13 UTC by Enji Cooper
Modified: 2015-02-27 07:18 UTC (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Enji Cooper freebsd_committer 2014-06-20 18:13:17 UTC
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.
Comment 1 Enji Cooper freebsd_committer 2014-06-20 18:14:18 UTC
The security team might want to audit this to ensure that this isn't a security vulnerability.
Comment 2 Xin LI freebsd_committer 2014-06-20 20:35:18 UTC
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.
Comment 3 Enji Cooper freebsd_committer 2014-06-20 20:39:23 UTC
(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.
Comment 4 Xin LI freebsd_committer 2014-06-20 20:50:36 UTC
(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.
Comment 5 Enji Cooper freebsd_committer 2014-06-20 20:59:53 UTC
(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?
Comment 6 Allan Jude freebsd_committer 2015-02-27 07:18:47 UTC
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.