Bug 147881 - [zfs] [patch] ZFS "sharenfs" doesn't allow different "exports" options for different hosts
Summary: [zfs] [patch] ZFS "sharenfs" doesn't allow different "exports" options for di...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: Unspecified
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-fs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-06-15 17:00 UTC by Richard S. Conto
Modified: 2020-02-23 20:17 UTC (History)
4 users (show)

See Also:


Attachments
file.diff (3.53 KB, patch)
2010-06-15 17:00 UTC, Richard S. Conto
no flags Details | Diff
fsshare.c-multipleexports.patch (723 bytes, patch)
2012-03-27 17:07 UTC, quentin.rameau
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Richard S. Conto 2010-06-15 17:00:01 UTC
I found that I was unable to selectively NFS export my ZFS filesystems such that some hosts had "-maproot=0" and others had "-maproot=nobody:nobody".

The syntax and operation of 'zfs set sharenfs="xxx" <poolname>' followed by "zfs share -a" doesn't allow for a multi-valued 'xxx'.

Fix: Here's a patch to the compatibility shim "fsshare.c" that allows the following syntax for "sharenfs='xxxx' where 'xxxx' can be:

(1) <export_options>... <export_hosts>...
(2) <export_options_1>... <export_hosts_1> ; <export_options_2>... <export_hosts_2>... ; ... <export_options_n>... <export_hosts_n>...

Empty sets of '<exports_options_n>... <exports_hosts_n>...' are allowed (i.e.: multiple ';'s with only whitespace between them.

Comments (with a leading '#') for '<exports_options_n>... <exports_hosts_n>...' are supported to allow a ZFS administrator to disable a particular configuration.

Patch attached with submission follows:
How-To-Repeat: (1) Set up ZFS based NFS host
(2) Set up two NFS clients, one which should have "root" access to the NFS exports from the ZFS host, one which shouldn't
(3) Try to make it so.
Comment 1 Mark Linimon freebsd_committer freebsd_triage 2010-07-18 16:41:41 UTC
Responsible Changed
From-To: freebsd-bugs->freebsd-fs

Over to maintainer(s).
Comment 2 Martin Birgmeier 2010-10-15 08:15:12 UTC
Please implement this or a similar patch. I need this in my dual 
IPv4/IPv6 setup, where it is necessary to have something like

/tank/vol   -network 192.168.0.0 -mask 255.255.0.0
/tank/vol   -network fec0:0:0:1::/56

in /etc/zfs/exports in order to get both IPv4 and IPv6 clients to work.

Regards,

Martin
Comment 3 Richard S. Conto 2010-10-21 22:10:19 UTC
My patch is IPv4/IPv6/DNS agnostic - it ought to work either way.  NFSv4 =
might be a problem due to the syntax differences in /etc/exports =
(/etc/zfs/exports).

All my patch does is use ';' as a special character to allow multiple =
values (like you want) for each export.  Each value is prefixed by the =
mount point and written to /etc/zfs/exports.


I'm still running it - but it's for a home file server where I want to =
restrict "root" access from certain VPNs.  Given that all it does is =
change the output to /etc/zfs/exports, which is handled by the regular =
NFS export mechanism, I don't think that there should be any significant =
difference between home and production/enterprise use - unless NFS =
exports keel over when there's hundreds of mount points (easy to do with =
ZFS) rather than tens.  My home set up is exporting only 25 mount =
points.

--- Richard



On Oct 15, 2010, at 3:15 AM, Martin Birgmeier wrote:

> Please implement this or a similar patch. I need this in my dual =
IPv4/IPv6 setup, where it is necessary to have something like
>=20
> /tank/vol   -network 192.168.0.0 -mask 255.255.0.0
> /tank/vol   -network fec0:0:0:1::/56
>=20
> in /etc/zfs/exports in order to get both IPv4 and IPv6 clients to =
work.
>=20
> Regards,
>=20
> Martin
Comment 4 quentin.rameau 2012-03-27 17:07:22 UTC
I made another similar patch which does not include commented lines.
It's for RELENG_9_0

-- 
Quentin Rameau
Comment 5 radek.krejca 2012-08-17 12:14:31 UTC
Thank you very much for patch, is there any time perspective of aplying thi=
s patch (or possibility) to system?

Richard, your patch has a little bug, if there is - in the hostname, it is =
expanded as whitespace and throw mistake to log.

Radek
Comment 6 Richard S. Conto 2012-08-17 19:58:02 UTC
On Aug 17, 2012, at 7:14 AM, Radek Krej=E8a wrote:

> Thank you very much for patch, is there any time perspective of =
aplying this patch (or possibility) to system?
>=20
> Richard, your patch has a little bug, if there is - in the hostname, =
it is expanded as whitespace and throw mistake to log.
>=20
> Radek

I've just applied my patch to FreeBSD-9 - and was thinking of expanding =
it in order to be able to deal with NFS-V4 exports.
(I was thinking of expanding '%f' as the filesystem name so the =
filesystem name can occur in any part of the string.)

Do you mean that if there is a "-" (hyphen) in the hostname, such as =
"my-nfs-clients.local.com"), it gets mangled?  I'll look at that.=
Comment 7 Martin Matuska freebsd_committer 2012-09-06 14:36:13 UTC
The purpose of the sharenfs property is not to completely replace
/etc/exports.
What we have is just a tricky workaround that populates /etc/zfs/exports.
T
he commands to NFS-share filesystems on illumos are different and our
options are mostly incompatible with illumos.
So you e.g. sharenfs="-maproot=root" is invalid if imported on a
Openindiana system.

Have you considered using just /etc/exports for more-complex configurations?

-- 
Martin Matuska
FreeBSD committer
http://blog.vx.sk
Comment 8 Richard S. Conto 2012-09-07 19:05:39 UTC
On Sep 6, 2012, at 9:36 AM, Martin Matuska wrote:

> The purpose of the sharenfs property is not to completely replace
> /etc/exports.
> What we have is just a tricky workaround that populates =
/etc/zfs/exports.
> T
> he commands to NFS-share filesystems on illumos are different and our
> options are mostly incompatible with illumos.
> So you e.g. sharenfs=3D"-maproot=3Droot" is invalid if imported on a
> Openindiana system.
>=20
> Have you considered using just /etc/exports for more-complex =
configurations?

Yes. It doesn't scale - and scaling is the whole purpose of NFS.  It =
also makes it difficult for distributed management of access rights to =
end-user NFS exports.

I wouldn't mind using a FreeBSD specific attribute to populate =
/etc/zfs/exports with FreeBSD specific values such as is used for =
swapping to ZFS.  Merging the two different attributes would either be =
tricky, or the use of the FreeBSD one should cause "sharenfs" to be =
ignored entirely.


> --=20
> Martin Matuska
> FreeBSD committer
> http://blog.vx.sk
>=20
Comment 9 Andrey Simonenko 2012-09-10 12:40:08 UTC
On Fri, Sep 07, 2012 at 06:10:07PM +0000, Richard Conto wrote:
>  
>  > The purpose of the sharenfs property is not to completely replace
>  > /etc/exports.
>  > What we have is just a tricky workaround that populates =
>  /etc/zfs/exports.
>  > T
>  > he commands to NFS-share filesystems on illumos are different and our
>  > options are mostly incompatible with illumos.
>  > So you e.g. sharenfs=3D"-maproot=3Droot" is invalid if imported on a
>  > Openindiana system.
>  >=20
>  > Have you considered using just /etc/exports for more-complex =
>  configurations?
>  
>  Yes. It doesn't scale - and scaling is the whole purpose of NFS.  It =
>  also makes it difficult for distributed management of access rights to =
>  end-user NFS exports.
>  
>  I wouldn't mind using a FreeBSD specific attribute to populate =
>  /etc/zfs/exports with FreeBSD specific values such as is used for =
>  swapping to ZFS.  Merging the two different attributes would either be =
>  tricky, or the use of the FreeBSD one should cause "sharenfs" to be =
>  ignored entirely.

This is a limitation of exports(5) format, that does not allow to specify
all settings for one file system in one line.  When I had similar task
I allowed to redefine options in one line, so address specifications can
inherit already specified settings and can get changed or new settings.

For example: /fs -ro -mapall user1 host1 -mapall user2 host2 host3 -rw host4

Here, /fs is exported read-only for host{1,2,3} and read-write for host4,
all users are mapped to user1 for host1 and all users are mapped to user2
for host{2,3,4}.

More information about format of NFS exports settings that I propose
is available here:

http://nfse.sourceforge.net/nfs.exports.5.html
Comment 10 Eitan Adler freebsd_committer freebsd_triage 2018-05-28 19:47:01 UTC
batch change:

For bugs that match the following
-  Status Is In progress 
AND
- Untouched since 2018-01-01.
AND
- Affects Base System OR Documentation

DO:

Reset to open status.


Note:
I did a quick pass but if you are getting this email it might be worthwhile to double check to see if this bug ought to be closed.
Comment 11 dgilbert 2019-05-31 23:48:14 UTC
Please note, on dual stack systems this is required by practically the _default_ configuration.  I was just rejiging my network a bit.  I had 100's of hosts listed in my nfsshare property.  It would all boil down to two network statements ... one ipv4 and one ipv6.

EPHASIS MINE: this is a DEFAULT CONFIG IMHO on DUAL STACK systems.

Something like sharenfs="-network 1234:5678:9012:3456::/64 -network 192.168.0.0/24"
Comment 12 Richard S. Conto 2019-06-03 14:41:27 UTC
I considered re-writing my patch to use a FreeBSD specific attribute for my syntax (or an expanded one that would allow white-space in the pathnames - but that would have involved modifying how the "exportfs" command parsed .../exports files.)

But frankly, this was a sort of proof-of-concept that addressed a need for adapting to the FreeBSD .../exports file format that wasn't being addressed.

And the FreeBSD project didn't care enough.

Of course there are compatibility issues with the Solaris version of ZFS - because "sharenfs" is implemented as a hack to begin with.

Pushing the administration of ZFS mount points into a hand-administered /etc/exports files ignores scalability issues.

The FreeBSD .../exports file format doesn't scale well and is an ugly hack itself.  A proper fix to this should include revisiting whether that file format should be extended or supplemented.
Comment 13 dgilbert 2019-06-03 16:15:24 UTC
So where do we go to have this "larger" conversation?  Is there a PR for the exports format?  Is there anyone working on the issue?  Can I work on the issue (still need to have the discussion since the format needs to make people happy to get adopted)...
Comment 14 Richard S. Conto 2019-06-03 21:26:46 UTC
If I knew, I'd try.

The format of the "exports" files in Linux, FreeBSD, and Solaris are different.  The FreeBSD "fsshare" utility is an attempt to approximate some of the functionality without considering the other aspects of Solaris sharing (including CIFS file sharing) and system administration that ZFS filesystem attributes encode.

Having a FreeBSD specific attribute for this seems like the best solution, as "nfsshare" is really a Solaris specific solution.
Comment 15 dgilbert 2019-06-03 22:10:17 UTC
(In reply to Richard S. Conto from comment #14)

... hrm... this is becoming _the_ place to discuss this, it seems.  Several people I've talked to have already noticed the activity.

Anyways... someone proposed the ';' solution ... to make multiple lines.  Someone else, I think (somewhere) said that there are hard limits on the length of zfs attributes.  The auto-snapshot bit in zfs-tools uses a "custom" attribute.

Putting these all together makes me think:

freebsd.org:export_0 = <line 1 of export>
freebsd.org:export_1 = <line 2 of export>

... it may even be true that export_<*> is available where the suffix could just be something meaninful to the admin in question.

To be clear, "<line 1 of export>" is the /etc/exports line without the path.
Comment 16 Rick Macklem freebsd_committer 2019-06-04 00:07:54 UTC
Personally, I think Quentin Rameau's patch is all you need.
I don't think embedded comments in the sharenfs property are needed
and it just makes the patch much more involved.
The one slightly scary thing about it is that "; ;" is allowed and results
in the file system being exported read/write to the world, because it will
generate a line with just the mountpoint in it. (I never use ZFS, so I don't
know if a blank sharenfs property is allowed and results in the same thing?)
It might be safer to not allow that case?

One other change would be to take the "const" off the argument for
translate_opts() and don't have it strlcpy() the shareopts, since they
have already be copied by the caller with Quentin's patch.

I don't recommend changing the exports(5) syntax for two reasons:
1- Any change must be 100% backwards compatible or it is a POLA violation
   and can't go in FreeBSD. (ie. Any exports file that worked before must
   still work and provide the same semantics.)
2 - Parsing of exports file(s) is done by a function called
    get_exportlist_one() in src/usr.sbin/mountd/mountd.c and, if you
    look at it, you will find the code convoluted and difficult to modify
    without breaking it.

I'm not a ZFS guy, so I can't help w.r.t. getting this in FreeBSD.
I'd suggest you post on a FreeBSD mailing list about this and hope that
someone on the ZFS side is interested in getting the patch in.
Comment 17 VVD 2019-10-25 21:56:32 UTC
Is there any chance of seeing this patch (fsshare.c-multipleexports.patch) soon in releng/12.1? stable/12? head?
Comment 18 VVD 2020-02-23 20:17:03 UTC
Does this patch have any problems?
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=107165&action=diff