[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 #5 from Rick Macklem <rmacklem@FreeBSD.org> ---
(In reply to systemdlete@fastmail.com from comment #3)
>Like it or lump it, it's a feature.


>>A feature--but then, further down, you acknowledge it /could/ be a bug.
If the two lines of "V4:" I suggested do not work, then
that might be considered a bug (or more correctly a limitation
that should be addressed).


>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?
I was referring to the protocol, not what a client might do to "attach"
a NFSv4 subtree. NFSv3 has a Mount sideband protocol, which are the RPCs
mountd(8) handles. NFSv4 does not have any "Mount" RPC.

>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.
Historically would refer to NFSv3, which is very different than NFSv4.
The exports(5) lines other than "V4:" export server file systems.
For NFSv4, you have two separate things. You have access to the file
systems (which is handled via the non-"V4:" lines) and you have state
information (not related to any server file system) which is handled by
the "V4:" lines.

>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.
See above.

>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 was simply noting the case I know works w.r.t. "V4:".
I know you can specify multiple "V4:" lines, but I couldn't
be bothered testing this case of multiple "V4:" lines, since
you can easily try it.

>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.
I agree "man exports" is confusing. You'll note that the example
in it shows two "V4:" lines, so it is definitely allowed.
It defines the location of the root (and there can only be one
of those) and the access allowed to that root for NFSv4 system
state.

Note that it states that it "simply mark's the location of the root..."
in the section describing the "first component". As such, it only refers
to the first component. Then it discusses the second and third components
(the flags and host/net addresses) separately and, yes, it erroneously
states "how the file system is" for the second component.
It should be something like "how the file system or NFSv4 root is".
It might be less confusing if it said "this type of line" instead of
"this line..." in the V4: description for the first component.

The man page has been rewritten multiple times.
Feel free to suggest man page changes, but preferably in phabricator
(reviews.freebsd.org) and not here.


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?
They define what file systems are exported vs where/what the NFSv4 root is.

>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 you do not try the above, we will not know if it
fixes your problem or if there is 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.
No, as above, you need both. The non-V4: lines specify the file systems
the client can access (and you've already seen that works). The "V4:"
lines handle the state, which is all the client "mount" is doing for NFSv4.

>>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).
Maybe their UI only generates one "V4:" line. If so, that is a bug in their
UI.

>>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.
This round might help?


>>At any rate, thank you for your feedback.
Bottom line, clients that you didn't export to cannot access files,
so they cannot do any real harm. They tie up a small amount of state
resources on the server, but that is all.

[reply

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