On Tue, 2011-07-19 at 14:51 -0500, Serge E. Hallyn wrote: 
> 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?

No.

> I thought it was only your devpts on the host?

Correct.

> In which case it is being propagated as a mount event.

Should be, I would think.

> -serge

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  m...@wittsend.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

Attachment: signature.asc
Description: This is a digitally signed message part

------------------------------------------------------------------------------
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

Reply via email to