ZFS sharenfs mangling NFS options

[Adrian Penisoara]

Hi,

  I was nicely surprised to see that the "sharenfs" option for a ZFS
dataset does the expected trick and automatically shares on NFS the
dataset via /etc/zfs/exports. However, I had some not so pleasant
experiences customizing the NFS sharing parameters -- e.g. when the
contents of the "sharenfs" property was automatically translated into
[/etc/zfs/]exports entries:
   * whatever hostname contains a "-" (dash) it gets malformed by
being split over the dash character
   * whatever NFS parameter is prefixed with a "-" (dash) and it's not
the first in the list it gets transformed into a hostname entry

  After some hunting into the CDDL sources I have been able to
pinpoint the exact (library) code doing the translation as function
translate_opts() in src/cddl/compat/opensolaris/misc/fsshare.c :

        while ((o = strsep(&s, "-, ")) != NULL) {
                if (o[0] == '\0')
                        continue;
                for (i = 0; known_opts[i] != NULL; i++) {
                        len = strlen(known_opts[i]);
                        if (strncmp(known_opts[i], o, len) == 0 &&
                            (o[len] == '\0' || o[len] == '=')) {
                                strlcat(newopts, "-", sizeof(newopts));
                                break;
                        }
                }
                strlcat(newopts, o, sizeof(newopts));
                strlcat(newopts, " ", sizeof(newopts));
        }

  If I'm able to read C correctly, then it looks like the code above
fails to take into consideration the case of hostnames containing
dashes and the case of options prefixed with dashes (although it is
advertised as valid format in the comments).

  On the other hand, I'm not too convinced that the contents of the
sharenfs property should be translated at all (when different from
values "on" and "off") -- I can't seem to find a good documentation
reference for [Open]Solaris, but it looks like they are expecting
share(1M) style options. I would assume then that for FreeBSD it would
await exports(5) style options, so then why was this translation step
needed anyway ?

  Take into account that known_opts[] is a statically assigned vector
of strings identifying valid exports(5) keywords -- thus it needs to
be kept in sync with mountd code, which was already the case recently
with new NFSv4 option(s).

  If any translation should be occurring at all then I would expect a
single common syntax for sharenfs among all OSes (e.g. share(1M) style
options) and the translation to be done over to the OS'es native
exports(5) format.

Thank you for your time,
Adrian Penisoara <ady (at) freebsd.ady.ro>
EnterpriseBSD.com