Page MenuHomeFreeBSD

nfs: Mark the NFS VFS as jail-safe
Needs ReviewPublic

Authored by des on Jul 17 2025, 1:18 PM.
Tags
None
Referenced Files
Unknown Object (File)
Wed, Oct 15, 2:47 PM
Unknown Object (File)
Wed, Oct 15, 2:47 PM
Unknown Object (File)
Fri, Oct 3, 1:22 AM
Unknown Object (File)
Sun, Sep 28, 3:13 AM
Unknown Object (File)
Sat, Sep 27, 10:18 PM
Unknown Object (File)
Wed, Sep 24, 10:54 AM
Unknown Object (File)
Sep 19 2025, 2:21 AM
Unknown Object (File)
Sep 13 2025, 8:02 AM
Subscribers

Details

Reviewers
kib
rmacklem
Summary

This makes it possible for a jail to mount an NFS file system, provided
it has the allow.mount.nfs property (which is off by default).

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped
Build Status
Buildable 65512
Build 62395: arc lint + arc unit

Event Timeline

des requested review of this revision.Jul 17 2025, 1:18 PM

NFS mounts are nowhere near safe inside jails as
far as I know.

There are a bunch of global variables that are not vnet'd
and when a NFS mount must do a TCP reconnect, there
will be problems. (The TCP reconnect must be done for
the correct vnet which is always vnet0 at this time.)

Putting the global variables within a vnet is not hard
to do (I did it in experimental code at one point).
The problem is that all sorts of threads (anything making
a VOP_xxx() call, for example) will need to set the
correct CURVNET_SET() and that just got too messy for me.

Now, I don't know enough about non-vnet jails to know
what might or might not be broken, but I ma sure vnet
jails are a "no go" for inside a jail.

In addition to what Rick wrote.

There are also not-VNET jails. In principle, it would be fine to globally enable NFS mounts for that kind of jails, since your patch implies that admin can overwrite the global permissions. OTOH, if kernel does tcp reconnect (or sends udp rpc packets from nfsiod threads) then indeed it would not be subject to the jail network namespace.

Suppose you have a system with...
/exports - exported so clients can NFS mount it.
/myjail - a subtree used for a non-vnet jail.

Wouldn't an NFS mount of /exports inside "myjail" just
violate the basic jail premise that it is the subtree under
/myjail that should be accessible? (ie. /myjail is the root of
the sandbox?)

I suppose if the code makes sure it is a non-vnet jail and
is only allowed when the allow.mount.nfs is set, this
could be ok?

I'm not conversant enough w.r.t. jails to know if there
is going to be a problem?
I suspect TCP reconnects might be problematic.
I'd suggest you try partitioning the client from the server
for long enough for the TCP connection to break and then
heal the network and see what happens?
(I think it needs to be wired to always use vnet0 for the TCP
reconnects and I'm not sure what is going to be set for the
credentials in the non-vnet jail?)

I have been tempted to do CURVNET_SET(vnet0), but the
jail folk did not like this.

des retitled this revision from nfs: Mark the NFS VFS as jail-safe. to nfs: Mark the NFS VFS as jail-safe.Aug 2 2025, 5:44 PM