ZFS filesystem: export for more than one subnet

[Jeremy Chadwick]

On Mon, Sep 08, 2008 at 02:43:03AM +0400, Dmitry Morozovsky wrote:
> On Sun, 7 Sep 2008, Jeremy Chadwick wrote:
> 
> JC> > is there any way so one can export ZFS file system to more than one net? 
> JC> > 
> JC> > in classic NFS I would use more than one line in /etc/exports -- how can I 
> JC> > express such behaviour in zfs properties?
> JC> 
> JC> Didn't you inadvertently ask this same question 6 months ago?  :-)
> JC> 
> JC> http://lists.freebsd.org/pipermail/freebsd-current/2008-March/084079.html
> 
> Well, not exactly - that time I did not bump into different destination problem 
> ;)
> 
> JC> I believe if 'sharenfs=off' (the default), you can manage NFS mounts via
> JC> /etc/exports like normal.  Ideally, you should (?) be able to use
> JC> multiple "-network xxx/netmask" entries on the same export line.
> 
> Hmm, that would do the trick; however, it seems to me that ZFS file system 
> properties should be producet from the single source.

I interpret this to mean "there should be only one export(5) file used".
That would be something to take up with pjd@, but I'm willing to bet
that behaviour is not going to change.  There is probably a good reason
why /etc/zfs/exports exists.

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

> JC> If you absolutely must do it via the 'zfs' command, according to pjd@'s
> JC> EuroBSDCon presentation, this should work:
> JC> 
> JC> # /etc/rc.d/mountd start
> JC> # zfs set sharenfs="ro,network=x.x.x.x,mask=y.y.y.y" some_fs
> JC> # /etc/rc.d/mountd reload
> 
> Well, this configures only one network per file system, isn't it? BTW, mountd 
> will be reloaded by zfs automagically (and, as Kris bumps ito it, it would 
> create a problem with race hole of inaccessible NFS mounts while mountd reloads 
> the list)

Does the below work?

# zfs set sharenfs="ro,network=aaa/xx,network=bbb/yy,network=ccc/zz" some_fs

If not (e.g. mountd rejects it, or only the first network is used), then
this would indicate a problem with the exports file syntax / problem
with mountd, and not with ZFS.

Solaris solves all of this, AFAIK, by having a central command that
manages the export list: share(1).  "zfs" on Solaris even calls this.
BSD does not have this utility.

> JC> However, I'd advocate you consider running pf on the machine running
> JC> mountd instead, and use an actual firewall to block who can talk to
> JC> mountd on the machine exporting the shares.
> 
> I would prefer to do both ;) Oh, and hosts.allow possibly too... Or, would it 
> be too inefficient?

There is absolutely no reason to do both.  Packets arriving on the
network will hit the pf stack before ever reaching mountd, which is
perfect, and a good security model.

Additionally, libwrap (hosts.allow/deny) is a travesty, and should be
nuked from the face of the planet.  It provides a false sense of
security -- it doesn't stop someone (anyone!) from being able to
actually connect to that TCP port (or in the case of UDP, I believe a
deny/rejection will actually send back a packet of some kind), which
means people will then know you've got (rpcbind|mountd|ftpd|whatever)
running, which gives an attacker/hacker significant hints about what
your system is running, and more ammunition.

-- 
| Jeremy Chadwick                                jdc at parodius.com |
| Parodius Networking                       http://www.parodius.com/ |
| UNIX Systems Administrator                  Mountain View, CA, USA |
| Making life hard for others since 1977.              PGP: 4BD6C0CB |