On Mon, Jul 18, 2011 at 7:36 AM, Serge E. Hallyn <se...@hallyn.com> wrote: > 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,
not a good idea if so :-) > (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), ahhh, i did not know it behaved like that ... hrmm. i knew you needed `-o bind` but i never even considered acting on the bind would *ever* affect the original mountpoint ... interesting, thanks. > 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. per your other comment, i didn't realize some distros --make-[r]shared / by default (or are mount points themselves shared by default? how to do that?) ... thats probably why i don't see this behavior; all my machines are Archlinux and we probably aren't changing the upstream defaults. >> 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. yes i see that. pretty much all i know was from hours of trial an error understanding the semantics ... definitely a few gotchas in there it would seem. however, while i could *maybe* see the rootfs being an unconditional slave, i would NOT want to see any lxc default/enforcement preventing container -> host propagation on a globally recursive scale. im of the opinion that the implementor should decide the best tactic ... especially in light of the fact the one distro may not even have the same problems as say ubutnu/fedora/etc because they keep mount points private by default. >The third is non sequitur :) beh :-) fair enough. i've been known to ramble on ... slowly degrading toward incohesive mumblings of interwoven thoughts in "real" life, so i suppose this is the digital manifestation of these tendencies ... <continues incoherently ...> C Anthony ------------------------------------------------------------------------------ Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ _______________________________________________ Lxc-users mailing list Lxc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-users