https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287977
Bug ID: 287977
Summary: ZFS NFS exports allows mounts by clients not in the
list of /etc/exports (though the files are
inaccessible anyway)
Product: Base System
Version: 14.3-RELEASE
Hardware: Any
OS: Any
Status: New
Severity: Affects Some People
Priority: ---
Component: conf
Assignee: [email protected]
Reporter: [email protected]
Summary of problem: Mounting an NFS file system that has been exported for only
certain clients (as specified in /etc/exports on the NFS server) by a client
that is not one of those clients results in a successful mount, even though
that client still cannot actually access files on that mounted filesystem.
This issue was first noticed on Xigmanas, but it seems to be rather generic re
freeBSD. So I have set up an example that illustrates this issue on a freeBSD
system here. Xigmanas is built on freeBSD, and even though I just upgraded that
freeBSD system to 14.2 (whereas Xigmanas is an older version), the behavior has
not changed, so this is a good testbed.
Here are listings of various tools on the freeBSD system (more of my notes at
the end):
zfs list
NAME USED AVAIL REFER MOUNTPOINT
zroot 9.18G 3.41G 96K /zroot
zroot/ROOT 7.57G 3.41G 96K none
zroot/ROOT/14.1-RELEASE_2025-06-06_173303 8K 3.41G 6.63G /
zroot/ROOT/14.2-RELEASE-p1_2025-06-06_173707 8K 3.41G 6.73G /
zroot/ROOT/default 7.57G 3.41G 6.80G /
zroot/filesystem1 96K 3.41G 96K
/zroot/filesystem1
zroot/filesystem2 96K 3.41G 96K
/zroot/filesystem2
zroot/home 124M 3.41G 104K /home
zroot/home/tester 124M 3.41G 124M /home/tester
zroot/tmp 24.5M 3.41G 24.5M /tmp
zroot/usr 1.46G 3.41G 96K /usr
zroot/usr/ports 1.46G 3.41G 1.46G /usr/ports
zroot/usr/src 96K 3.41G 96K /usr/src
zroot/var 1.14M 3.41G 96K /var
zroot/var/audit 96K 3.41G 96K /var/audit
zroot/var/crash 96K 3.41G 96K /var/crash
zroot/var/log 664K 3.41G 664K /var/log
zroot/var/mail 120K 3.41G 120K /var/mail
zroot/var/tmp 96K 3.41G 96K /var/tmp
df
Filesystem 1K-blocks Used Avail Capacity Mounted on
zroot/ROOT/default 10710140 7130944 3579196 67% /
devfs 1 0 1 0% /dev
procfs 8 0 8 0% /proc
zroot/tmp 3604256 25060 3579196 1% /tmp
zroot/usr/ports 5106100 1526904 3579196 30% /usr/ports
zroot/usr/src 3579292 96 3579196 0% /usr/src
zroot/var/log 3579860 664 3579196 0% /var/log
zroot/var/audit 3579292 96 3579196 0% /var/audit
zroot/var/crash 3579292 96 3579196 0% /var/crash
zroot/var/mail 3579316 120 3579196 0% /var/mail
zroot/home 3579300 104 3579196 0% /home
zroot/var/tmp 3579292 96 3579196 0% /var/tmp
zroot 3579292 96 3579196 0% /zroot
zroot/home/tester 3705920 126724 3579196 3% /home/tester
zroot/filesystem1 3579292 96 3579196 0% /exports/exportfs1
zroot/filesystem2 3579292 96 3579196 0% /exports/exportfs2
mount
zroot/ROOT/default on / (zfs, local, noatime, nfsv4acls)
devfs on /dev (devfs)
procfs on /proc (procfs, local)
zroot/tmp on /tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot/usr/ports on /usr/ports (zfs, local, noatime, nosuid, nfsv4acls)
zroot/usr/src on /usr/src (zfs, local, noatime, nfsv4acls)
zroot/var/log on /var/log (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/var/audit on /var/audit (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/var/crash on /var/crash (zfs, local, noatime, noexec, nosuid, nfsv4acls)
zroot/var/mail on /var/mail (zfs, local, nfsv4acls)
zroot/home on /home (zfs, local, noatime, nfsv4acls)
zroot/var/tmp on /var/tmp (zfs, local, noatime, nosuid, nfsv4acls)
zroot on /zroot (zfs, local, noatime, nfsv4acls)
zroot/home/tester on /home/tester (zfs, local, noatime, nfsv4acls)
zroot/filesystem1 on /exports/exportfs1 (zfs, NFS exported, local, noatime,
nfsv4acls)
zroot/filesystem2 on /exports/exportfs2 (zfs, NFS exported, local, noatime,
nfsv4acls)
cat /etc/exports
/exports/exportfs1 -mapall="root" -network 10.10.50.0/24
/exports/exportfs2 -mapall="root" -network 10.10.50.0/24
/exports/exportfs2 -mapall="root" -network 192.168.200.0/24
V4: /exports
ifconfig
em0: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0
mtu 1500
options=48104bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,LRO,VLAN_HWFILTER,HWSTATS,MEXTPG>
ether 08:00:27:ba:8a:59
inet 172.25.80.7 netmask 0xffffff00 broadcast 172.25.80.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
em1: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0
mtu 1500
options=48505bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,LRO,VLAN_HWFILTER,VLAN_HWTSO,HWSTATS,MEXTPG>
ether 08:00:27:6b:9e:74
inet 172.25.10.5 netmask 0xffffff00 broadcast 172.25.10.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
em2: flags=1008843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST,LOWER_UP> metric 0
mtu 1500
options=48505bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,LRO,VLAN_HWFILTER,VLAN_HWTSO,HWSTATS,MEXTPG>
ether 08:00:27:97:63:31
inet 192.168.200.1 netmask 0xffffff00 broadcast 192.168.200.255
media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
nd6 options=29<PERFORMNUD,IFDISABLED,AUTO_LINKLOCAL>
lo0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384
options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
inet 127.0.0.1 netmask 0xff000000
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
groups: lo
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
rc.conf
hostname="test-freebsd"
ifconfig_em0="inet 172.25.80.7 netmask 255.255.255.0"
ifconfig_em1="inet 172.25.10.5 netmask 255.255.255.0"
ifconfig_em2="inet 192.168.200.1 netmask 255.255.255.0"
defaultrouter="172.25.80.1"
local_unbound_enable="YES"
sshd_enable="YES"
moused_enable="YES"
ntpd_enable="YES"
ntpd_sync_on_start="YES"
powerd_enable="YES"
# Set dumpdev to "AUTO" to enable crash dumps, "NO" to disable
dumpdev="AUTO"
zfs_enable="YES"
vboxguest_enable="YES"
vboxservice_enable="YES"
firewall_enable="NO"
nfs_client_enable="YES"
nfs_client_flags="-o nfsvers=4"
nfs_server_enable="YES"
nfsv4_server_enable="YES"
I hope I have configured ZFS correctly here. Both /zroot/filesystem1 and
/zroot/filesystem2 were created as datasets (which I believe are treated as
file systems in ZFS) and are mounted at (hopefully) separate mount points under
the root /export mount point, as illustrated by the mount listing. The
/etc/fstab file on the NAS does not reference the ZFS filesystems.
A side note before proceeding further concerns a feature of NFS 4.2 called
"trunking detection." It sounds like the sort of feature that could undermine
attempts to keep restricted access by separate export mounts on the server; but
my scenario restricts all traffic to one route directly between the FreeBSD (or
Xigmanas) server and the client. Therefore, I believe that trunking detection
can be disregarded for this more limited test environment. (I only accidentally
tripped over this topic while looking for a solution or explanation for my own
scenario; there does not appear to be much information about the feature
generally.)
Note that each of the two exported ZFS file systems are designated for separate
client communities. Also note that there is NO such network as 10.10.50.0/24,
so there is no way that NFS resources would be shared to that network. I did
this on purpose, to illustrate the scenario clearly. If it doesn't exist, it
cannot possibly be a factor. (Note that this also conveniently eliminates the
trunking detection issue mentioned above.) I only included the exports here to
reproduce a similar scenario on the Xigmanas, which does, by contrast, have 2
live interfaces. Incidentally, the freebsd system where I am performing this
test is NOT running a firewall, whereas my Xigmanas system does run the ipfw
firewall, but hopefully that won't make a difference for the purposes of this
testing.
Now, there are other network interfaces on the freeBSD system I have set up,
but the sole client I have set up only has one interface, and that is
configured for the 192.168.200.2/24 network, which is configured for one of the
freeBSD system's interfaces at 192.168.200.1/24; the two systems can talk to
each other without any issues, and there are no other hosts on the
192.168.200.0/24 subnet. The objective here is to demonstrate that the sole
client should be able to mount and access the files on /exports/exportfs2, but
should fail trying to mount /exports/exportsfs1.
For this test, I created an NFS client on a Devuan Beowulf system with only one
interface, configured for 192.168.200.2/24. But this same problem scenario I am
reporting also occurs with my Xigmanas providing NFS to various Devuan Chimaera
and Daedalus, and Alpine Linux, NFS clients.
When the sole NFS client mounts /exportfs2, it succeeds, and it can access the
files on that exported filesystem, as expected. However, when the client mounts
/exportfs1, it also succeeds, which I did not expect since I specified in the
/etc/exports file that only systems on the 10.10.50.0/24 network should have
access to /exportfs2. The successful mount from the sole client can be
confirmed by running netstat or similar on the server side and on the client
side. Thus, there is no question that the client has the the restricted file
system mounted even though it should not be, and the server believes that it is
mounted by the client as well, which I expected would have thrown an error.
Note that the sole client, even though successfully mounting the /exportfs1
file system, cannot actually access the files on that file system.
(I know that ZFS can perform NFS itself, but that is not how I am doing it here
because I want to reproduce the original issue seen on the Xigmanas.)
Is this legitimately a bug, or have I misconfigured something? If the problem
is misconfiguration, then it must be on the server side (Xigmanas/FreeBSD/ZFS)
since a client that is not supposed to have permission to access the server's
resources should be expected to fail to mount. NFS server-side security cannot
be left vulnerable to a client configuration issue.
--
You are receiving this mail because:
You are the assignee for the bug.
