V_* meta-symbols and locking

[Julian Elischer]

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