(sorry, just realized postfix has been messing up my email, hope this comes through ok) Quoting C Anthony Risinger (anth...@xtfx.me): > On Jul 15, 2011 12:01 PM, "Michael H. Warfield" <m...@wittsend.com> wrote: > > > > Unfortunately, I also still find that if there's a -o remount,ro in the > > halt/reboot script, it still sets /dev/pts to ro and that still > > propagates to the host and to the other containers triggering random > > acts of terrorism like "unable to create pty/0" in the containers and > > inability to start new containers in the host. Not sure if we can apply > > a bind to that or not. > > Doesn't `-o newinstance` mount option to devpts mounts prevent this? It
I haven't looked further than reading Michael's email, but a plausible sequence is that (a) the container's rootfs is just a bind mount from the parent's, (b) the mount -o remount,ro is not being done with 'bind' and so affects the fs, not the mount (as helpfully pointed out a few weeks ago on irc by dhansen), and so (c) the fs on which the host's /var/lib/lxc/<container>/rootfs is mounted gets recursively mounted ro, and the host's /dev/pts is under that. > should privatize the devices for each ... its best to mount host this way > too -- then set symlink for each: > > /dev/ptmx -> /dev/pts/ptmx > > > The kernel should also prohibit, totally, the propagation of remount > > options from inside a container to the outer host or to other > > containers. That is tantamount to a security vulnerability and clearly > > a violation of container isolation. > > 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. See '(b)' above. You're sort of mixing mounts propagation with bind mounts subtleties. Your second sentence in that paragraph is 100% correct. The third is non sequitur :) See the patch I just sent in response to Michael's email. thanks, -serge ------------------------------------------------------------------------------ Storage Efficiency Calculator This modeling tool is based on patent-pending intellectual property that has been used successfully in hundreds of IBM storage optimization engage- ments, worldwide. Store less, Store more with what you own, Move data to the right place. Try It Now! http://www.accelacomm.com/jaw/sfnl/114/51427378/ _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users
