From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 20:22:29 2008 Return-Path: Delivered-To: freebsd-virtualization@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8FA56106566B for ; Wed, 18 Jun 2008 20:22:29 +0000 (UTC) (envelope-from julian@elischer.org) Received: from outD.internet-mail-service.net (outd.internet-mail-service.net [216.240.47.227]) by mx1.freebsd.org (Postfix) with ESMTP id 6D99F8FC0C for ; Wed, 18 Jun 2008 20:22:29 +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 125812408; Wed, 18 Jun 2008 13:22:29 -0700 (PDT) Received: from julian-mac.elischer.org (localhost [127.0.0.1]) by idiom.com (Postfix) with ESMTP id B515D2D6006; Wed, 18 Jun 2008 13:22:28 -0700 (PDT) Message-ID: <48596E8B.6010906@elischer.org> Date: Wed, 18 Jun 2008 13:22:35 -0700 From: Julian Elischer User-Agent: Thunderbird 2.0.0.14 (Macintosh/20080421) MIME-Version: 1.0 To: Marko Zec References: <48588595.7020709@gritton.org> <48593586.9040600@elischer.org> <48595DB2.3030005@gritton.org> <200806182140.23123.zec@icir.org> In-Reply-To: <200806182140.23123.zec@icir.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: freebsd-virtualization@freebsd.org Subject: Re: V_* meta-symbols and locking 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: Wed, 18 Jun 2008 20:22:29 -0000 Marko Zec wrote: > On Wednesday 18 June 2008 21:10:42 James Gritton wrote: >> Julian Elischer wrote: >> >>> the man page for vimage(8) says for the chroot parameter: >> >>> >> >>> chroot >> >>> Set the chroot directory for the virtual image. All new >> >>> processes spawned into the target virtual image using the vimage >> >>> command will be initially chrooted to that directory. This >> >>> parameter can be changed only when no processes are running >> >>> within the target virtual image. Note that it is not required to >> >>> have a chrooted environment for a virtual image operate, which >> >>> is also the default behavior. >> >>> >> >>> so the croot is fixed unless there is no-one using it. >> > >> > Note that one could also read "or children images" I think in some >> > of >> >> these checks.. >> >> >> The situation with setting the chroot path becomes more complicated >> the more I look at it. If I replicate the vimage behavior of being >> able to set jails more than one level below the current jail >> (i.e. create "foo.bar.baz" which would be placed under the current >> "foo.bar"), then there's not necessarily a connection between place >> in the prison hierarchy and the file hierarchy. I could create jail >> "foo.bar" rooted at /home/foo/bar and then create "foo.bar.baz" >> rooted at /home/baz. That's kind of nonintuitive. > > True. Chrooting "foo.bar.baz" at absolute path > of /home/foo/bar/home/baz could be a more logical action. > >> Or perhaps I >> could restrict the chroot pathname lookup not to the caller's root, >> but to the parent jail's root. But pathnames that are looked up with >> something other that the root of the process doing the looking is >> also rather counterintuitive. >> >> And then there's the possibility of changing the root path. Suppose >> I have "foo" at /home/foo and "foo.bar" at home.bar. If I then >> change foo's home to /jail/foo, does foo.bar's jail likewise change >> to /home/foo/bar? What if /jail/foo/bar doesn't exist? Should the >> whole thing fail, or would I have foo now at /jail/foo and foo.bar at >> /home/foo/bar? I could just not recursively re-root child jails when >> I change a chroot path - except I still should if foo.bar isn't >> separately chrooted and also lives at /home/foo. >> >> Making things even worse, jail allows relative chroot paths. Those >> saved pathnames (used for prison_canseemount and >> prison_enforce_statfs) are totally useless when the erstwhile current >> directory is unknown. I'd just not allow them, but the current >> behavior of rendering all mount points essentially invisible under >> such circumstances seems reasonable. But there'd certainly be no way >> to relate a relative chroot pathname to its place in any parent >> jails. >> >> The upshot of all this is that for now, I'm sticking with only >> allowing the path to be set when a jail is created. >> >> The vimage implementation of all this seems to consist entirely of >> the quoted man page, so I can't just go there for answers. > > vimage(8) simply invokes chroot(2) to the target directory (stored a > plaintext string in the kernel) before spawning a new process inside > the target VM. > > Obviously such an approach has served only as a proof of concept hack > (though there's some anecdotal evidence some ISPs have been making > money using precisely such vimage implementation on FreeBSD 4.11). > Hence, don't feel constrained by the legacy of such kludges, and feel > free to propose better alternatives. The only thing I'd like to have > as an option is to be able to spawn a new process in the target VM > _without_ making it chrooted... I'd say that there is no choice.. it has to be chrooted.. to something.. but that chroot could be either the chroot of the parent or a subdirectory of that. it can not be a directory back toward the root from the parent's chroot. > > Marko