julian at elischer.org
Thu May 14 17:33:05 UTC 2009
Jamie Gritton wrote:
> 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 think I may have replied before but it all looks pretty good to me..
> 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
>> 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.
not sure why you want to keep hostname a true global
It seems to me that it is an eminently virtalizable property.
though possible a special hostname might exist for the base system
for error messages etc.
kind of like V_hostname an G_hostname :)
otherwise I agree.
>> 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.
I agree with this in principle and we'll see ow it works out in practice.
>> 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.
I looked at that too.
All in all, I like it.
>> - Jamie
> freebsd-virtualization at freebsd.org mailing list
> To unsubscribe, send any mail to
> "freebsd-virtualization-unsubscribe at freebsd.org"
More information about the freebsd-jail