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
