From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 19:40:44 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 7240F1065673 for ; Wed, 18 Jun 2008 19:40:44 +0000 (UTC) (envelope-from zec@icir.org) Received: from xaqua.tel.fer.hr (xaqua.tel.fer.hr [161.53.19.25]) by mx1.freebsd.org (Postfix) with ESMTP id ED1D98FC16 for ; Wed, 18 Jun 2008 19:40:43 +0000 (UTC) (envelope-from zec@icir.org) Received: by xaqua.tel.fer.hr (Postfix, from userid 20006) id CF0079B649; Wed, 18 Jun 2008 21:40:42 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.1.7 (2006-10-05) on xaqua.tel.fer.hr X-Spam-Level: X-Spam-Status: No, score=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.7 Received: from [192.168.200.112] (zec2.tel.fer.hr [161.53.19.79]) by xaqua.tel.fer.hr (Postfix) with ESMTP id 782E49B64F; Wed, 18 Jun 2008 21:40:40 +0200 (CEST) From: Marko Zec To: freebsd-virtualization@freebsd.org Date: Wed, 18 Jun 2008 21:40:22 +0200 User-Agent: KMail/1.9.7 References: <48588595.7020709@gritton.org> <48593586.9040600@elischer.org> <48595DB2.3030005@gritton.org> In-Reply-To: <48595DB2.3030005@gritton.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200806182140.23123.zec@icir.org> Cc: Julian Elischer 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 19:40:44 -0000 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... Marko