From owner-freebsd-virtualization@FreeBSD.ORG Sat May 9 06:46:44 2009 Return-Path: Delivered-To: virtualization@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id D2416106566B for ; Sat, 9 May 2009 06:46:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outL.internet-mail-service.net (outl.internet-mail-service.net [216.240.47.235]) by mx1.freebsd.org (Postfix) with ESMTP id B6E408FC12 for ; Sat, 9 May 2009 06:46:44 +0000 (UTC) (envelope-from julian@elischer.org) Received: from idiom.com (mx0.idiom.com [216.240.32.160]) by out.internet-mail-service.net (Postfix) with ESMTP id EAC7A6C719; Fri, 8 May 2009 23:47:03 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (unknown [24.114.252.230]) by idiom.com (Postfix) with ESMTP id 219AF2D600F; Fri, 8 May 2009 23:46:43 -0700 (PDT) Message-ID: <4A0526D7.7090000@elischer.org> Date: Fri, 08 May 2009 23:46:47 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.21 (Macintosh/20090302) MIME-Version: 1.0 To: Jamie Gritton References: <4A051DE3.30705@FreeBSD.org> In-Reply-To: <4A051DE3.30705@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: virtualization@FreeBSD.org, jail@FreeBSD.org Subject: Re: Hierarchical jails X-BeenThere: freebsd-virtualization@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion of various virtualization techniques FreeBSD supports." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 May 2009 06:46:45 -0000 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"