Date: Wed, 18 Jun 2008 21:40:22 +0200 From: Marko Zec <zec@icir.org> To: freebsd-virtualization@freebsd.org Cc: Julian Elischer <julian@elischer.org> Subject: Re: V_* meta-symbols and locking Message-ID: <200806182140.23123.zec@icir.org> In-Reply-To: <48595DB2.3030005@gritton.org> References: <48588595.7020709@gritton.org> <48593586.9040600@elischer.org> <48595DB2.3030005@gritton.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200806182140.23123.zec>