V_* meta-symbols and locking

[James Gritton]

Marko Zec wrote:

 >>> 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...
 >>
 >> If you mean creating a jail that's not chrooted, that's no problem.
 >> If you mean creating a jail that *is* chrooted, and then placing a
 >> process into that jail without chrooting it, that would be a breakage
 >> of the jail paradigm.  Hopefully you mean the former?
 >
 > No, I want the later, as an option.  Given that the parent environment /
 > jail completely controls the child anyhow, I don't think such an
 > (optional) behavior would be too big a security issue.


I'm thinking of the security implications, but of the mess.  The
existing jail_attach() wouldn't be sufficient, as it only passes a
jid.  You'd need a separate jail_attach2() sysctl call.  Would this be
exactly the same as jail_attach() except that it doesn't do the chroot?
That sounds like a one-off to me.  So would you instead have a way of
specifying which parts of the jail environment you do and don't want?
Then you'd have to not only know what virtualizations a jail does and
doesn't do (the problem I'm working on), but also what virtualizations
every process in a jail may or may not have enabled.  It might be that
only the chroot can reasonable support this kind of split anyway.

Why do you want this?  If you want to be part of the jail, you attach
to it.  If you want to do administration of the jail environment, it
should be sufficient to do it from outside.

- Jamie