V_* meta-symbols and locking

[Julian Elischer]

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.  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.


I beieve you can not change a chroot if there are
1/ running processes
2/ children vimages..

effectively this means that you really only have one chance to 
reparent a vimage, and that is right after you have created it.

Once it has children (either processes or vimages), you have "fixed
it.

I do think that the chroot path needs to be expressed when creating it 
in the terms of the parent vimage. If no chroot is specified then
it gets what its parent had.. I have not actually looked (yet) to see
what Marko has done here.. (wanders off to do so)



> 
> 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