All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Serge E. Hallyn" <serue-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
To: "Michael H. Warfield" <mhw-UGBql2FAF+1Wk0Htik3J/w@public.gmane.org>
Cc: containers-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org
Subject: Re: Mount remount operations propagating from container to host and	other containers.
Date: Thu, 1 Apr 2010 09:50:54 -0500	[thread overview]
Message-ID: <20100401145054.GE22648@us.ibm.com> (raw)
In-Reply-To: <1270129248.7564.43.camel@localhost>

Quoting Michael H. Warfield (mhw-UGBql2FAF+1Wk0Htik3J/w@public.gmane.org):
> Hey all,
> 
> Been running into an ugly situation with LXC-Tools that seems to be
> pointing up a real serious leakage from containers.  If you have a mount
> inside a container (presumably a bind mount in this case), if the
> container does a mount -o remount (say rw->ro or ro->rw) this propagates
> to the host mount points (all the way to the primary mount point for
> that partition in some cases) and is reflected in other containers.

I think you'll want to mount --make-rslave or --make-rprivate
during container setup.  Distros vary with how they leave /
set up, and if it is all rshared from the start, then yeah
your containers' mount actions will propagate backward.

> This first show up with containers running full VM's running on a
> mounted fs (aot the host / fs) were causing the real mounted fs to
> become ro when they were shut down (the VM was remounting its rootfs as
> ro and it was leaking out of the container).
> 
> I've since confirmed that and encountered it trying to have a shared ro
> mounted fs in a container using bind mounts (bind mounts since 2.6.26
> have allowed setting the ro flag on individual mount points) and
> discovering that one container could make it rw and then all the other
> containers would see it as rw as well!  If a container made a mount
> point ro, all the other containers would see it as ro and the mount
> point for the entire real fs in the host would become ro!  This is very
> not good.  That's a pretty serious leakage from the containers out to
> the host.
> 
> Is this a problem with the container isolation or some problem in
> creating the container?
> 
> I'm running and testing on a Fedora 12 system with a 2.6.32 kernel.  Not
> related (I don't think) but I have also noted that linux-utils-ng on F16
> seems to also have a bug irt something similar here.  If I mount a
> directory from a mounted partition onto another location and then make
> that other location ro, the entire partition becomes ro.  BUT!  If I
> then make the partition rw, that does not propagate back up and the bind
> mount remains ro.
> 
> What should work is this:
> 
> Partition /export
> Directory /export/readonly
> 
> mount --bind /export/readonly /srv/readonly
> 
> At this point, /export and /srv/readonly are both rw
> 
> mount -o remount,ro /srv/readonly
> 
> Now. both /export and /srv/readonly are ro!  This is wrong.
> Only /srv/readonly is suppose to be ro!
> 
> Now, running...
> 
> mount -o remount,rw /export
> 
> now, /export is rw and /srv/readonly is readonly.
> 
> Back to containers...
> 
> If I have /srv/readonly mounted in several containers (same mount point)
> it's ro in the host and in the containers...
> 
> Running this in one container:
> 
> mount -o remount,rw /srv/readonly
> 
> (I seriously wish this would NOT WORK AT ALL, but it does.  I don't want
> the container to be able to write to that partition at all, like the
> media was RO.  Anybody have any ideas on that one?)
> 
> Now /srv/readonly is rw in the host and all the containers!
> 
> (EVEN WORSE!)
> 
> Running this in one container:
> 
> mount -o remount,ro /srv/readonly
> 
> NOW /srv/readonly is ro in all the containers and /export is ro in the
> host.  NOT GOOD.
> 
> Thoughts?
> 
> Regards,
> Mike
> -- 
> Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw-BetbSzk+GohWk0Htik3J/w@public.gmane.org
>    /\/\|=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!



> _______________________________________________
> Containers mailing list
> Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
> https://lists.linux-foundation.org/mailman/listinfo/containers

  reply	other threads:[~2010-04-01 14:50 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-01 13:40 Mount remount operations propagating from container to host and other containers Michael H. Warfield
2010-04-01 14:50 ` Serge E. Hallyn [this message]
2010-04-01 15:00 ` Serge E. Hallyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100401145054.GE22648@us.ibm.com \
    --to=serue-r/jw6+rmf7hqt0dzr+alfa@public.gmane.org \
    --cc=containers-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org \
    --cc=mhw-UGBql2FAF+1Wk0Htik3J/w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.