Date: Mon, 09 Jun 2008 11:07:14 -0600 From: James Gritton <jamie@gritton.org> To: freebsd-virtualization@freebsd.org Subject: jail_set Message-ID: <484D6342.1080901@gritton.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?484D6342.1080901>