From owner-freebsd-jail@FreeBSD.ORG Thu May 14 17:33:04 2009 Return-Path: Delivered-To: jail@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 5401C1065670 for ; Thu, 14 May 2009 17:33:04 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outE.internet-mail-service.net (oute.internet-mail-service.net [216.240.47.228]) by mx1.freebsd.org (Postfix) with ESMTP id 358CD8FC2C for ; Thu, 14 May 2009 17:33:04 +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 03221B9859; Thu, 14 May 2009 10:33:04 -0700 (PDT) X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e X-Client-Authorized: MaGic Cook1e Received: from julian-mac.elischer.org (home.elischer.org [216.240.48.38]) by idiom.com (Postfix) with ESMTP id 5CC522D6018; Thu, 14 May 2009 10:33:03 -0700 (PDT) Message-ID: <4A0C55CF.70706@elischer.org> Date: Thu, 14 May 2009 10:33:03 -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> <4A0C5112.9010103@FreeBSD.org> In-Reply-To: <4A0C5112.9010103@FreeBSD.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: virtualization@FreeBSD.org, jail@FreeBSD.org, FreeBSD Current Subject: Re: Hierarchical jails X-BeenThere: freebsd-jail@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Discussion about FreeBSD jail\(8\)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 May 2009 17:33:05 -0000 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"