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

[Michael H. Warfield]

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

Problem...

      lxc-start 1311083210.678 ERROR    lxc_conf - failed to turn child rootfs into slave
      lxc-start 1311083210.678 ERROR    lxc_conf - failed to setup rootfs for 'Alcove'
      lxc-start 1311083210.678 ERROR    lxc_start - failed to setup the container
      lxc-start 1311083210.679 ERROR    lxc_sync - invalid sequence number 1. expected 2
      lxc-start 1311083210.679 ERROR    lxc_start - failed to spawn 'Alcove'


This may be do to the way I have my rootfs set up.  Mine are bind mounts
from a private area to the common mount point.  I've noticed that inside
the containers, I see my root file system show up twice like this (over
on one of my production machines):

[mhw at Berserker ~]$ df
Filesystem           1K-blocks      Used Available Use% Mounted on
rootfs               480719056 404550544  51749312  89% /
/dev/sdb1            480719056 404550544  51749312  89% /
/dev/sdc1            480719056    202816 456097040   1% /export
/dev/sda7            693727244 624715768  33772100  95% /srv/shared
none                   1030612         0   1030612   0% /dev/shm

[mhw at berserker-base ~]$ cat /srv/lxc/config/Berserker.fstab 
/srv/lxc/private/Berserker /srv/lxc/rootfs               none bind 0 0

/export               /srv/lxc/rootfs/export        none bind 0 0
/home/shared          /srv/lxc/rootfs/srv/shared    none bind 0 0


Maybe not such a good idea (mine)?

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/c5bd1312/attachment.pgp>