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