[lxc-devel] mount ro in guest change host filesystem to ro

[Michael H. Warfield]

On Fri, 2011-09-02 at 08:35 +0400, Michael Tokarev wrote: 
> On 02.09.2011 00:46, Daniel Lezcano wrote:
> > On 09/01/2011 09:30 PM, Nico wrote:
> >> Hi,
> >>
> >> I just wanted to give it a try again with lxc after one year,
> >> this is so bad same bugs are always here :
> >>
> >> * you can do a "mount -o romount,ro /" inside container (reported
> >> since first times ... :( ),
> >> and host filesystem is remounted ro !!
> > 
> > Argh ! I still don't understand how that can happen with a CLONE_NEWNS
> > and a pivot_root.
> > Do you have particular mount options on your host's rootfs ?

> In order for guest remount to NOT influence host mount, you have to
> give -o bind option to mount inside guest.  If you don't specify
> MS_BIND with MS_REMOUNT, the remount applies to _host_ mountpoint,
> not guest.

Last time I recall playing with this was a couple of months ago and was
not the rootfs that was causing me headaches with random acts of
terrorism but the devpts file system mounted on /dev/pts.  When a
container would to a remount ro (the evil deed in the "halt" script that
was causing the problems) it would make ALL of the devpts mounts in the
host and in all of the other containers ro, and you were screwed till
you remounted it rw once again.  At the time, we played with things like
SLAVE, SHARED, and PRIVATE mounting with bind mounts and I had it
(mostly?) working for real file systems, like additional mounts, but
never did get it working for the pseudo file systems like devpts.

Now, you're saying, what we need to do is do a bind mount in the
container after the clone?  So lxc has to do this for every mount (not
just /) after cloning the container and before firing up init?  Do I
have that right?

I then see a potential problem right there (even assuming that works for
devpts - which I really hope it would).  What if someone in the
container mounts a new instantiation of devpts and then remounts it as
ro?  Will that propagate or no?

Blocking all mounts is not acceptable as there are too many things where
a container might want to do a mount on say iso images or something
similar.  Certainly the case if you are using this for development
systems (I work on the Network Security Toolkit run live iso from time
to time for instance).

Serge said something about needed to set up a test environment to
reproduce it but that was the last I heard from him on the subject back
then.  I wasn't sure if he was implying that it wasn't happening on an
Ubuntu host (I'm using Fedora) or what exactly.

> This has been discussed several times on irc.

Would have been nice if it had been echoed on the E-Mail channel.  I
don't look in on irc that often and E-Mail threads are better preserved,
specially when you've been disconnected for a while.  :-/

> /mjt

Regards,
Mike
-- 
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-devel/attachments/20110902/016e4cc5/attachment.pgp>