Re: Hierarchical jails

There's still a change to offer your input on the new jails before they
go in!  OK, given the lack of response so far, it's less "still a
chance" than "please?".  Current plans are to have this in place for
8.0, with connections to the ongoing Vimage work.  Hopefully the silence
is approval, and commits will likely be appearing soon.


I wrote:
> Here's the first round of hierarchical jails under the new framework.
> 
> Instead of creds having either a prison or a NULL pointer, they all have
> a prison pointer with the default being the global "prison0" that
> contains information about the real environment.  Jailed root may (if
> granted permission) create prisons that would be under its place in the
> hierarchy, but may not alter (or even see) prisons at its level or
> above.
> 
> The JID space is flat, i.e. every prison in the system has a unique ID.
> The prison name space is hierarchical, with jails having dot-separated
> component names.
> 
> prison0 contains three fields that were system globals: pr_root,
> pr_host, and pr_securelevel.  I've kept the globals rootvnode and
> hostname, and take care that when one is changed the other changes too
> (not yet true for hostname - read on).  But I've actually removed the
> global securelevel, instead forcing people to use securelevel_gt() and
> securelevel_ge() (or in very rare cases to check prison0.pr_securelevel
> directly).  I chose to do that because while using the global rootvnode
> and hostname may be incorrect, using the wrong securelevel is, well,
> insecure.  Actually it would be insecure to use the wrong rootvnode too,
> but I'm not convinced removing that global is worth the headache.
> 
> Other globals are subsumed into prison0, but they were only ever part of
> the jail system anyway: the various jail-related permission bits and
> such administrative things as prisoncount.
> 
> The prison hierarchy keeps track of restrictions placed on prisons, and
> will reflect them downward so a child jail is always at least as
> restricted as its ancestors.  It doesn't go the other way though: if a
> prison's restrictions are loosened, the children stay as they are.
> 
> This patch doesn't have anything for userland, and hierarchical jails
> won't work without that patch (because jails don't have permission to
> create sub-jails by default, and jail(2) can't grant that permission).
> A userland patch will follow soon, very similar to the version I posted
> here recently.
> 
> - Jamie