Quoting Michael H. Warfield (m...@wittsend.com): > On Tue, 2011-07-19 at 12:59 -0500, Serge E. Hallyn wrote: > > Quoting Michael H. Warfield (m...@wittsend.com): > > > I think the problem is that you are only doing this on the rootfs and > > > that flag does not automagically propagate to the submounts. That's > > > D'oh! Yeah, what you want is MS_REC | MS_SLAVE. The rest should be fine > > as I had it? > > Well, you still need the patch for /rootfs->path/rootfs->mount/ on the > second parameter to that mount call. > > I gave it a shot. No error on the build or running lxc-start but... No > joy. A remount,ro still propagates back into the host from the > container. > > Been reading the kernel Documentation/filesystems/sharedsubtree.txt file > about the SHARED, PRIVATE, and SLAVE semantics and it doesn't sound like > it does what we think it does. It will stop the propagation of mounts > themselves from master to slave and vice versa but I don't see anything > about remounts. I mean, I can see it argued both ways. Well, you're > not really propagating a mount because it's already mounted. Yeah, but > it is propagating the mount action. That file is not clear on what > action would take place in the case of a remount like this. > > This comment in section 5a of that file seems to favor the second > interpretation that shared or private should affect remounts: > > == > A 'propagation event' is defined as event generated on a vfsmount > that leads to mount or unmount actions in other vfsmounts. > == > > Is a remount a "mount action"? I would presume it is.
But wait, is your rootfs remounted ro? I thought it was only your devpts on the host? In which case it is being propagated as a mount event. -serge ------------------------------------------------------------------------------ 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
