Date: Fri, 08 May 2009 23:46:47 -0700 From: Julian Elischer <julian@elischer.org> To: Jamie Gritton <jamie@FreeBSD.org> Cc: virtualization@FreeBSD.org, jail@FreeBSD.org Subject: Re: Hierarchical jails Message-ID: <4A0526D7.7090000@elischer.org> In-Reply-To: <4A051DE3.30705@FreeBSD.org> References: <4A051DE3.30705@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Jamie Gritton 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. agree > > 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. this matches vimage, and I agree. > > 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. fair enough at this time. > > 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. yes. I agree. > > 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 patch removed by mailng list... (but I saw it in the privately received version...) > > > ------------------------------------------------------------------------ > > _______________________________________________ > 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?4A0526D7.7090000>