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