[Bug 287977] ZFS NFS exports allows mounts by clients not in the list of /etc/exports (though the files are inaccessible anyway)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=287977

--- Comment #3 from systemdlete@fastmail.com <systemdlete@fastmail.com> ---
>Like it or lump it, it's a feature.

A feature--but then, further down, you acknowledge it /could/ be a bug.

>Why?
>Because for NFSv4, there is no concept of
>a "mount". 

How else can a client get access to the remote file system if it does not mount
it?

>Although you used names I don't recognize, I
>suspect they are Linux variants.

Not sure which "names" you are referring to, but devuan is debian without
systemd.  Xigmanas is an appliance based on freebsd.

>The only time the "mount" might fail is if it
>is restricted by the "V4:" export line.

I thought it was restricted based on the /other/ lines in the file.  At least,
that's how NFS /etc/exports worked historically.

>As you note, the clients do not have access to
>the files, which is what the exports(5) lines
>other than the "V4:" one specifies.

Yep.  Those are the ones I am referring to (take a look; it's all there in my
OP).  So I don't understand your most previous remark.

>tw, if all your exports were to the same
>subnet, that subnet could be put on the "V4:"
>line and then the NFSv4 mounts would probably
>fail.

But they're not.  I intentionally want to export only some file systems to some
subnets.  (Also in my OP.)

>I think you can specify multiple "V4:" lines
>with different subnets.

Some of the docs I have encountered so far (I've been exploring one rabbit hole
after another for a month now) indicate that there can only be one V4: line in
the exports file.  But perhaps you can point me to the correct documentation. 
It is quite possible I glossed right over it.

My reading of the docs and the xigmanas UI labels/comments led me to think that
the V4: line was simply to specify the root of all the exports.

If what you are saying is true, then what does NFS use those other exports line
for?

>Try replacing:
>V4: /exports
>
>with:
>V4: /exports -network 10.10.50.0/24
>V4: /exports -network 192.168.200.0/24
>
>I am not sure if this will work, but worth
>a try. If it doesn't work, that does seem like
>a bug.

If what you say is accurate, then perhaps those "V4:" lines are supposed to be
the ONLY configuration lines for NFSv4 exports, distinguishing them apart
completely from prior NFS versions, meaning that those other lines are for
non-v4 exports and maybe don't apply to any v4 exports.  IOW, maybe NFSv4
intends to completely ignore the other non-"V4:" lines entirely?   If so, then
I have been thinking about this all wrong from the get-go and have wasted a
month trying to solve this.

Keep in mind that nearly all of the configuration I am using came straight out
of the files generated by xigmanas, which has a UI rather than a command line
interface (but obviously, the admin can access the files directly if needed;
that's how I pulled the configs for the vanilla freebsd configuration at hand).
 I guess I have been following the xigmanas-generated configuration files
thinking they must be correct.

Also note that the most recent release of xigmanas is running freebsd
13.3-RELEASE-p4, and might even have a custom kernel.  I'd prefer not to use
their nightlies except on a test system (which I have available, and maybe I
should try if all else fails).

I appreciate your having responded to my inquiry/report/whatever it turns out
to be.  I had difficulty following your response because it seems to be
self-contradictory in places, but that might be how I am reading it.  I will
re-read the NFSv4 docs more thoroughly than I have over the past month and see
if I can figure this out.  I'll try your solution, and then--if it works--I'll
go back and ponder why xigmanas generated the files it did.

At any rate, thank you for your feedback.

-- 
You are receiving this mail because:
You are the assignee for the bug.