From: ebiederm@xmission.com (Eric W. Biederman)
To: Andy Lutomirski <luto@amacapital.net>
Cc: Andrew Vagin <avagin@parallels.com>,
Andrey Vagin <avagin@openvz.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linux API <linux-api@vger.kernel.org>,
Andrey Vagin <avagin@gmail.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Andrew Morton <akpm@linux-foundation.org>,
Cyrill Gorcunov <gorcunov@openvz.org>,
Pavel Emelyanov <xemul@parallels.com>,
Serge Hallyn <serge.hallyn@canonical.com>,
Rob Landley <rob@landley.net>
Subject: Re: [PATCH] [RFC] mnt: add ability to clone mntns starting with the current root
Date: Wed, 08 Oct 2014 12:23:52 -0700 [thread overview]
Message-ID: <87vbnue56f.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <CALCETrX4XrgbQNZZa7=1009KqhJ2gT+VBUkC15+59K9yEiTSbQ@mail.gmail.com> (Andy Lutomirski's message of "Wed, 8 Oct 2014 08:35:22 -0700")
Andy Lutomirski <luto@amacapital.net> writes:
> On Wed, Oct 8, 2014 at 4:08 AM, Andrew Vagin <avagin@parallels.com> wrote:
>> On Tue, Oct 07, 2014 at 01:45:22PM -0700, Eric W. Biederman wrote:
>>> Andrey Vagin <avagin@openvz.org> writes:
>>>
>>> > From: Andrey Vagin <avagin@gmail.com>
>>> >
>>> > Currently when we create a new container with a separate root,
>>> > we need to clone the current mount namespace with all mounts and then
>>> > clean up it by using pivot_root(). A big part of mountpoints are cloned
>>> > only to be umounted.
>>>
>>> Is the motivation performance? Because if that is the motivation we
>>> need numbers.
>>
>> The major motivation to create a clean mount namespace which contains
>> only required mounts.
>>
>> Now you want to convince us that there is nothing wrong if we use
>> userns, because all inherited mounts are locked. My point is that all
>> useless mounts should be umounted. If the current root isn't on rootfs,
>> pivot_root() allows us to umount all useless points. But pivot_root()
>> doesn't work, if the current root is on rootfs. How can we umount
>> useless points in this case?
One of your justifications for a new system call was so you could do
less. Doing less to get to where you want to go is only justified when
your doing less to get better performance.
It sounds like your actual concern is about sandboxing and security
audits. That is a very legitimate concern. That isn't however the core
concern of containers, so it was not clear that is what you meant.
>> Maybe we want to say that rootfs should not be used if we are going to
>> create containers...
Today it is an assumption of the vfs that rootfs is mounted. With
rootfs mounted and pivot_root at the base of the mount stack you can
make as minimal of a set of mounts as the vfs allows.
Removing rootfs from the vfs requires an audit of everything that
manipulates mounts. It is not remotely a local excercise.
One of the things that needs to be considered is that if you really want
to audit mounts is the code that needs manipulates them needs to be
audited every bit as much as the mounts themselves.
> Could we have an extra rootfs-like fs that is always completely empty,
> doesn't allow any writes, and can sit at the bottom of container
> namespace hierarchies? If so, and if we add a new syscall that's like
> pivot_root (or unshare) but prunes the hierarchy, then we could switch
> to that rootfs then.
Or equally have something that guarantees that rootfs is empty and
read-only at the time the normal root filesystem is mounted. That is
certainly a much more localized change if we want to go there.
I am half tempted to suggest that mount --move /some/path / be updated
to make the old / just go away (perhaps to be replaced with a read-only
empty rootfs). That gets us into figuring out if we break userspace
which is a big challenge.
Eric
next prev parent reply other threads:[~2014-10-08 19:24 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-07 12:12 Andrey Vagin
2014-10-07 13:30 ` Al Viro
2014-10-07 13:33 ` Al Viro
2014-10-07 19:44 ` Andrew Vagin
2014-10-07 20:30 ` Eric W. Biederman
2014-10-07 20:46 ` Serge Hallyn
2014-10-07 20:52 ` Eric W. Biederman
2014-10-07 21:32 ` Serge Hallyn
2014-10-07 21:42 ` Eric W. Biederman
2014-10-07 22:19 ` Andy Lutomirski
2014-10-07 22:42 ` Eric W. Biederman
2014-10-07 22:44 ` Andy Lutomirski
2014-10-07 23:42 ` Eric W. Biederman
2014-10-07 23:44 ` Andy Lutomirski
2014-10-08 0:20 ` Eric W. Biederman
2014-10-08 0:25 ` Andy Lutomirski
2014-10-07 21:02 ` Andy Lutomirski
2014-10-07 21:26 ` Eric W. Biederman
2014-10-07 21:38 ` Andy Lutomirski
2014-10-07 21:50 ` Eric W. Biederman
2014-10-07 21:52 ` Andy Lutomirski
2014-10-07 21:33 ` Serge Hallyn
2014-10-07 20:45 ` Eric W. Biederman
2014-10-08 11:08 ` Andrew Vagin
2014-10-08 15:35 ` Andy Lutomirski
2014-10-08 19:23 ` Eric W. Biederman [this message]
2014-10-08 19:31 ` Andy Lutomirski
2014-10-08 21:36 ` Rob Landley
2014-10-08 22:01 ` Andy Lutomirski
2014-10-08 23:38 ` Serge Hallyn
2014-10-08 23:41 ` Andy Lutomirski
2014-10-08 21:23 ` Rob Landley
2014-10-09 10:29 ` Andrew Vagin
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=87vbnue56f.fsf@x220.int.ebiederm.org \
--to=ebiederm@xmission.com \
--cc=akpm@linux-foundation.org \
--cc=avagin@gmail.com \
--cc=avagin@openvz.org \
--cc=avagin@parallels.com \
--cc=gorcunov@openvz.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=rob@landley.net \
--cc=serge.hallyn@canonical.com \
--cc=viro@zeniv.linux.org.uk \
--cc=xemul@parallels.com \
/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
Powered by JetHome