jail_set
James Gritton
jamie at gritton.org
Mon Jun 9 17:07:20 UTC 2008
I've gotten the first stage working of the extensible name-based jail
settings framework, with a patch available at
http://gritton.org/jail_set.diff
This is based around a new jail_set() system call, much like nmount() -
in fact it even uses the same vfs options calls. It allows for modules
(the existing "prison services" hooks that zfs use) to have be
controlled via this interface, both to enable or disable the entire
module, or to have their own module-specific parameters.
The old jail() system call still exists and is compatible with this
setup - it just becomes a stub to jail_set with the "path", "hostname",
and "ip_number" parameters.
There's also a sysctl tree security.jail.jid, that shows all parameters
for current jails, once again with hooks for per-module parameters.
The expectation is that vimage's vnet and vinet will become prison
services under this framework, and the other more minor vimage bits will
be rolled in as well. This would fit in with the goals of the 21 Jul
deadline in Julian's recently posted schedule.
Work still to do:
Allow for hierarchical jails (which vimage needs).
Actually integrate this with vimage.
Integrate with other subsystems, more for proof of concept than anything
else. SYSV IPC perhaps, since I've already done similar work on them.
Or replace the one-off "pr_linux" hook on the prison structure with the
standard services hook.
Perhaps add a jail_get() system call, to read jail parameters.
Currently, they can be read via sysctl, but that might not be the best
way around this. If there's both a jail_set and jail_get, there may be
no need for the extra effort of the sysctl tree.
- Jamie
More information about the freebsd-virtualization
mailing list