Date: Thu, 14 May 2009 10:33:03 -0700 From: Julian Elischer <julian@elischer.org> To: Jamie Gritton <jamie@FreeBSD.org> Cc: virtualization@FreeBSD.org, jail@FreeBSD.org, FreeBSD Current <freebsd-current@FreeBSD.org> Subject: Re: Hierarchical jails Message-ID: <4A0C55CF.70706@elischer.org> In-Reply-To: <4A0C5112.9010103@FreeBSD.org> References: <4A051DE3.30705@FreeBSD.org> <4A0C5112.9010103@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A0C55CF.70706>