ZFS filesystem: export for more than one subnet

[Dmitry Morozovsky]

On Sun, 7 Sep 2008, Jeremy Chadwick wrote:

JC> That said, what happens if you edit /etc/zfs/exports by hand, then run
JC> "zfs list -o sharenfs"?  Does it show the changes you put in place?  If
JC> so, then great -- it means there's two ways a person can edit the
JC> NFS-exported ZFS shares (by editing the file directly, or using "zfs").

Nope, ZFS does not track /etc/zfs/export, hence "Do not edit!" comment in it.

JC> Does the below work?
JC> 
JC> # zfs set sharenfs="ro,network=aaa/xx,network=bbb/yy,network=ccc/zz" some_fs
JC> 
JC> If not (e.g. mountd rejects it, or only the first network is used), then
JC> this would indicate a problem with the exports file syntax / problem
JC> with mountd, and not with ZFS.

It is of course FreeBSD' mountd problem (more than it does not understand CIDR 
slashed notation):

marck at beaver:~# cat /etc/zfs/exports
# !!! DO NOT EDIT THIS FILE MANUALLY !!!

/FreeBSD        -ro -alldirs -network 195.54.192.0 -mask 255.255.255.192
255.255.255.192
marck at beaver:~# zfs get sharenfs bv/FreeBSD
NAME        PROPERTY  VALUE                                                     SOURCE
bv/FreeBSD  sharenfs  -ro -alldirs -network 195.54.192.0 -mask 255.255.255.192  local
marck at beaver:~# zfs set sharenfs="ro,alldirs,network=195.54.192.0/26,192.168.39.0/24" bv/FreeBSD
marck at beaver:~# zfs get sharenfs bv/FreeBSD
NAME        PROPERTY  VALUE                                               SOURCE
bv/FreeBSD  sharenfs  ro,alldirs,network=195.54.192.0/26,192.168.39.0/24  local


Sep  8 11:18:18 beaver mountd[25992]: can't get address info for host 192.168.39.0/24
Sep  8 11:18:18 beaver mountd[25992]: bad host 192.168.39.0/24, skipping
Sep  8 11:18:18 beaver mountd[25992]: network/host conflict
Sep  8 11:18:18 beaver mountd[25992]: bad exports list line /FreeBSD    -ro -alldirs -network


JC> > I would prefer to do both ;) Oh, and hosts.allow possibly too... Or, would it 
JC> > be too inefficient?
JC> 
JC> There is absolutely no reason to do both.  Packets arriving on the
JC> network will hit the pf stack before ever reaching mountd, which is
JC> perfect, and a good security model.
JC> 
JC> Additionally, libwrap (hosts.allow/deny) is a travesty, and should be
JC> nuked from the face of the planet.  It provides a false sense of
JC> security -- it doesn't stop someone (anyone!) from being able to
JC> actually connect to that TCP port (or in the case of UDP, I believe a
JC> deny/rejection will actually send back a packet of some kind), which
JC> means people will then know you've got (rpcbind|mountd|ftpd|whatever)
JC> running, which gives an attacker/hacker significant hints about what
JC> your system is running, and more ammunition.

Well, all there actually make sense.  Thanks, I'll think about it a little bit 
more.

Sincerely,
D.Marck                                     [DM5020, MCK-RIPE, DM3-RIPN]
[ FreeBSD committer:                                 marck at FreeBSD.org ]
------------------------------------------------------------------------
*** Dmitry Morozovsky --- D.Marck --- Wild Woozle --- marck at rinet.ru ***
------------------------------------------------------------------------