[Lxc-users] [PATCH] Re: read only rootfs

Michael H. Warfield mhw at WittsEnd.com
Tue Jul 19 17:10:33 UTC 2011


On Mon, 2011-07-18 at 07:31 -0500, Serge E. Hallyn wrote: 
> Quoting Michael H. Warfield (mhw at 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.hallyn at 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.hallyn at 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 at 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 at 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 |  mhw at 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!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.linuxcontainers.org/pipermail/lxc-users/attachments/20110719/96370e9c/attachment.pgp>


More information about the lxc-users mailing list