From: "Michael H. Warfield" <mhw-BetbSzk+GohWk0Htik3J/w@public.gmane.org>
To: containers-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@public.gmane.org
Subject: Mount remount operations propagating from container to host and other containers.
Date: Thu, 01 Apr 2010 09:40:48 -0400 [thread overview]
Message-ID: <1270129248.7564.43.camel@localhost> (raw)
[-- Attachment #1.1: Type: text/plain, Size: 3262 bytes --]
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.
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!
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]
[-- Attachment #2: Type: text/plain, Size: 206 bytes --]
_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linux-foundation.org/mailman/listinfo/containers
next reply other threads:[~2010-04-01 13:40 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-01 13:40 Michael H. Warfield [this message]
2010-04-01 14:50 ` Mount remount operations propagating from container to host and other containers Serge E. Hallyn
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=1270129248.7564.43.camel@localhost \
--to=mhw-betbszk+gohwk0htik3j/w@public.gmane.org \
--cc=containers-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b@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.