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