V_* meta-symbols and locking
julian at elischer.org
Wed Jun 18 20:22:29 UTC 2008
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
>> 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.
More information about the freebsd-virtualization