From owner-freebsd-virtualization@FreeBSD.ORG Wed Jun 18 19:10:50 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 A71911065678 for ; Wed, 18 Jun 2008 19:10:50 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from gritton.org (gritton.org [161.58.222.4]) by mx1.freebsd.org (Postfix) with ESMTP id 4AA388FC2A for ; Wed, 18 Jun 2008 19:10:49 +0000 (UTC) (envelope-from jamie@gritton.org) Received: from guppy.corp.verio.net (fw.oremut02.us.wh.verio.net [198.65.168.24]) (authenticated bits=0) by gritton.org (8.13.6.20060614/8.13.6) with ESMTP id m5IJAlEG009060; Wed, 18 Jun 2008 13:10:48 -0600 (MDT) Message-ID: <48595DB2.3030005@gritton.org> Date: Wed, 18 Jun 2008 13:10:42 -0600 From: James Gritton User-Agent: Thunderbird 2.0.0.9 (X11/20080228) MIME-Version: 1.0 To: freebsd-virtualization@freebsd.org References: <48588595.7020709@gritton.org> <4858ADCC.1050909@elischer.org> <48593036.60502@gritton.org> <48593586.9040600@elischer.org> In-Reply-To: <48593586.9040600@elischer.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.93, clamav-milter version 0.93 on gritton.org X-Virus-Status: Clean 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:10:50 -0000 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. 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. - Jamie