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 10:00:04 -0500 [thread overview]
Message-ID: <20100401150004.GF22648@us.ibm.com> (raw)
In-Reply-To: <1270129248.7564.43.camel@localhost>
Quoting Michael H. Warfield (mhw-UGBql2FAF+1Wk0Htik3J/w@public.gmane.org):
> 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?)
That is what the work to make VFS respect hierarchical user namespaces
is for. Alas it is a perennial victim of time shortages. It would
let you mark that fs as being owned by root in the initial user
namespace. Then root in a child user namespace would only get the
world access rights (like any other stranger user) to the fs and its
files. If an fs or files should be owned by user 500 in a container,
then inode->i_uid will actually store 500, the fs will store a
user ns id (which only a particular uid in init_user_ns can associate
with a container) in which user 500 is valid, and optionally userids
to use for file access from higher user namespaces. So the file is
owned by userid 500 in userns 5 which is a child of init_user_ns,
userns 5 is owned by userid 1000 in init_user_ns, so the file is owned
by userid 1000 in init_user_ns.
There are quite a few threads in the containers mailing list archive
between Eric and I about this, if you're interested in the background.
Part of the reason this work seems to refuse to get past 5-patch
prototypes is that only Eric and I seem to be interested. Maybe now
that there is a serious growing user base around lxc that will change.
-serge
prev parent reply other threads:[~2010-04-01 15:00 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
2010-04-01 15:00 ` Serge E. Hallyn [this message]
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=20100401150004.GF22648@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.