Re: Hierarchical jails

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
>> above.

agreed

>>
>> 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.

agreed

>>
>> 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
> http://lists.freebsd.org/mailman/listinfo/freebsd-virtualization
> To unsubscribe, send any mail to 
> "freebsd-virtualization-unsubscribe_at_freebsd.org"