<p><br>
On Jul 15, 2011 12:01 PM, "Michael H. Warfield" <<a href="mailto:mhw@wittsend.com">mhw@wittsend.com</a>> wrote:<br>
><br>
> Unfortunately, I also still find that if there's a -o remount,ro in the<br>
> halt/reboot script, it still sets /dev/pts to ro and that still<br>
> propagates to the host and to the other containers triggering random<br>
> acts of terrorism like "unable to create pty/0" in the containers and<br>
> inability to start new containers in the host.  Not sure if we can apply<br>
> a bind to that or not.</p>
<p>Doesn't `-o newinstance` mount option to devpts mounts prevent this?  It should privatize the devices for each ... its best to mount host this way too -- then set symlink for each:</p>
<p>/dev/ptmx -> /dev/pts/ptmx</p>
<p>> The kernel should also prohibit, totally, the propagation of remount<br>
> options from inside a container to the outer host or to other<br>
> containers.  That is tantamount to a security vulnerability and clearly<br>
> a violation of container isolation.</p>
<p>But not all use cases are system containers, eg 100% isolated.  Isn't a slave mount enough to prevent this?  I'd have to check but I *thought* bind mounts only responded to the `ro` flag ... and the new mount NS I'd think would play a role too ... not sure details offhand.</p>

<p>C Anthony [mobile]</p>