V_* meta-symbols and locking

[Marko Zec]

On Wednesday 18 June 2008 22:07:57 James Gritton wrote:
> 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.

Consider a situation where the directory tree of a jail would get 
corrupted or compromised (by accident or maliciously), so that you 
couldn't or wouldn't wish to exec any binaries from that part of the 
filesystem tree, but you'd like to check the network state / setup 
there (TCP connections, routes, firewall...), perhaps do a tcpdump 
capture and store it in a file inaccessible to processes already 
running in that jail...

Marko