Linux Container Development
 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox