Date: Wed, 18 Jun 2008 13:10:42 -0600 From: James Gritton <jamie@gritton.org> To: freebsd-virtualization@freebsd.org Cc: Julian Elischer <julian@elischer.org> Subject: Re: V_* meta-symbols and locking Message-ID: <48595DB2.3030005@gritton.org> In-Reply-To: <48593586.9040600@elischer.org> References: <48588595.7020709@gritton.org> <4858ADCC.1050909@elischer.org> <48593036.60502@gritton.org> <48593586.9040600@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?48595DB2.3030005>