Mount remount operations propagating from container to host and other containers.
Serge E. Hallyn
serue at us.ibm.com
Thu Apr 1 08:00:04 PDT 2010
Quoting Michael H. Warfield (mhw at wittsend.com):
> 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.
More information about the Containers