On Mon, 2011-07-18 at 07:31 -0500, Serge E. Hallyn wrote: > Quoting Michael H. Warfield (m...@wittsend.com): > > 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 > > Wow. > > Did a quick grep; is there any reason why lxc-start doesn't turn on > MS_SLAVE for the client's root? Something like: > > From 7fbc3ec940403605c53b253d8630c3f47fad154c Mon Sep 17 00:00:00 2001 > From: Serge Hallyn <serge.hal...@ubuntu.com> > Date: Mon, 18 Jul 2011 07:29:57 -0500 > Subject: [PATCH 1/1] (untested) turn container rootfs into MS_SLAVE > > Signed-off-by: Serge Hallyn <serge.hal...@ubuntu.com> > --- > src/lxc/conf.c | 5 +++++ > 1 files changed, 5 insertions(+), 0 deletions(-) > > diff --git a/src/lxc/conf.c b/src/lxc/conf.c > index 2eb598b..d36fe47 100644 > --- a/src/lxc/conf.c > +++ b/src/lxc/conf.c > @@ -732,6 +732,11 @@ static int setup_rootfs(const struct lxc_rootfs *rootfs) > return -1; > } > > + if (mount(rootfs->path, rootfs->path, "none", MS_SLAVE, 0)) { > + ERROR("failed to turn child rootfs into slave"); > + return -1; > + } > + > DEBUG("mounted '%s' on '%s'", rootfs->path, rootfs->mount); > > return 0; > -- > 1.7.4.1
I poked at this some more. First, I stuck a "perror" in that if check right after the mount to find out what it was griping about... [root@forest SPECS]# lxc-start --name Alcove setup_rootfs, MS_SLAVE: Invalid argument lxc-start: failed to turn child rootfs into slave lxc-start: failed to setup rootfs for 'Alcove' lxc-start: failed to setup the container lxc-start: invalid sequence number 1. expected 2 lxc-start: failed to spawn 'Alcove' Yuck. Invalid argument? Then I started thinking... Wasn't something missing in that command. Wouldn't you need those flags to be "MS_REMOUNT | MS_SLAVE" since you're remounting? Tried that. No joy. Same error. Sooo... I looked up at mount_rootfs called from the stanza above it. Tried adding the MS_SLAVE to the mount command proper in mount_rootfs_dir and commenting out the remount block entirely. The file system mounts properly but adding MS_SLAVE didn't solve the problem. :-P That should have been the right spot. Then I noticed a discrepancy. In mount_rootfs_dir mount it called with path and target while back in setup_rootfs the remount is calling it with path and path. Ah ha... So I changed that mount to read like this: if (mount(rootfs->path, rootfs->mount, "none", MS_REMOUNT|MS_SLAVE, 0)) { Again. Fixed the code but not the problem. 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 sort of implied by the way the man page for the mount command reads. It doesn't mention a "slave" option on individual file systems but has a --make-rslave function which recursively makes that mountpoint and all its submountpoints into slaves. Tried running mount --make-slave /dev/pts in the container and didn't get an error but still didn't fix the problem but I figured that would be too easy and it needed to be done back in lxc proper. At that point, I went through src/lxc/conf.c and added MS_SLAVE to every mount call. Yes, overly aggressive but just for a "shotgun test". It ran. But still failed the test. If I remount /dev/pts as ro in the container, I still get it ro in the host. Then remount rw in the container and it's back to rw in the host. Is this a kernel bug or what am I missing here? Strange too (and I just noticed this) is that I have two mount instances of devpts on /dev/pts: [root@alcove mhw]# mount -t devpts devpts on /dev/console type devpts (rw,relatime,mode=600,ptmxmode=666) devpts on /dev/tty1 type devpts (rw,relatime,mode=600,ptmxmode=666) devpts on /dev/tty2 type devpts (rw,relatime,mode=600,ptmxmode=666) devpts on /dev/tty3 type devpts (rw,relatime,mode=600,ptmxmode=666) devpts on /dev/tty4 type devpts (rw,relatime,mode=600,ptmxmode=666) devpts on /dev/tty5 type devpts (rw,relatime,mode=600,ptmxmode=666) devpts on /dev/tty6 type devpts (rw,relatime,mode=600,ptmxmode=666) devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=666) devpts on /dev/pts type devpts (rw,relatime,mode=600,ptmxmode=666) I don't have any devpts mounts in either the container /etc/fstab, the fstab lxc is referencing, or in any lxc.mount.entry in the config file. Why are there two of them there and is that indicative of a problem? Regards, Mike > > The kernel should also prohibit, totally, the propagation of remount > > The kernel doesn't know about containers, so it's up to userspace :) > > -serge > -- 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!
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