V_* meta-symbols and locking

[James Gritton]

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