Date: Tue, 17 Dec 2024 15:46:53 -0600 From: Kyle Evans <kevans@FreeBSD.org> To: freebsd-jail@freebsd.org Subject: Re: setting VNET tunables in a new jail Message-ID: <8985a3c8-65ce-45ac-8012-3708d0c07deb@FreeBSD.org> In-Reply-To: <Z2Hq704UowT2mz2v@nuc> References: <Z2Hq704UowT2mz2v@nuc>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/17/24 15:19, Mark Johnston wrote: > We have a number of sysctls which are defined as tunables, whose values > cannot be changed after boot. Some of these sysctls, such as net.fibs, > are per-VNET so could in principle be changed at jail creation time. > I'd find it useful to be able to pass a set of tunables to jail_set(2), > so that corresponding VNET jail has tunables set to the specified > values. For instance, it'd be useful in test suites where I want to > exercise the network stack with different VNET sysctl settings, without > having to configure the test runner at boot time. > > I think the implementation would involve passing an environment to > vnet_alloc(), which would copy the parent VNET context and then iterate > over all VNET tunables in the system, invoking > sysctl_load_tunable_by_oid_locked() in such a way that the custom > environment is used to update the tunable's value. > Related-ish, I've wanted to float the idea of "virtualizing" kenv by making it a property of struct prison instead of global. Primarily, because: 1) kenv today is super wide-open. Unprivileged users and jails can all view kenv, and while we do an OK-ish job of zapping privileged stuff from it, we do have some notable exceptions that it'd be better to not leak. 2.) I can imagine some use-cases for products where kenv is read from userland, being able to override those on a per-jail basis for product testing is generally a good thing (as an extension of the idea of just sysctl-tunables) We'd address #1 by just switching the targets for fetching/dumping in kenv(2) to the jail's own kenv, and possibly keeping it immutable without a priv(9). With the right design, vnet_alloc() wouldn't need to become aware of an environment; just the rest of your proposal. Thanks, Kyle Evans
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?8985a3c8-65ce-45ac-8012-3708d0c07deb>