Re: RFC: nfsd in a vnet jail

On 2022-12-01 08:37, Alan Somers wrote:
>> I don't care for any of it. It looks like additional overhead with the
>> addition of potential security risks. All for a very limited (and as yet
>> unknown) use case.
> 
> Here's an example of a real-world use case.  I'm responsible for
> supporting multiple products involving NFS, iSCSI, and other
> protocols.  For security reasons, each product is placed on its own
> VLAN.  Sometimes it's not practical to dedicate a physical server to a
> single product, so I have to double-up.  For the products that don't
> involve NFS or iSCSI, I place them in a VNET jail.  That way their
> processes can only access the correct VLAN.  But NFS and iSCSI can't
> (yet) be jailed, so those products need to be served by JID 0.
> Therefore, those products' processes can access each other's VLANs.
> Clearly that's not ideal.
> 
> Jailing different products is also good for manageability.  It's
> easier to manage the list of packages that must be installed for each
> product, config file settings, etc.  For example, some of our NFS
> products require vfs.nfsd.enable_stringtouid=1, but others could work
> without it.  Right now, we're forced to turn it on for all products.
OK. I can see that. Assuming I understand your intent correctly, I might
choose bhyve(8) for that. Tho that *would* be a little more expensive.
I rely on jail(8) daily. They're cheap, fast && easy. As yet, I've never
had unreasonable concern for security. The proposed change looks like a
potentially high addition of overhead (jail not so cheap now?). RPC &&
NFS are not cheap && have a comparatively high attack surface. So I guess
my concerns/view are affected by this understanding.

Thanks for the clarification, Alan.

--chris
> 
> -Alan