From: Andrew Vagin <avagin@gmail.com>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>,
Andrey Vagin <avagin@openvz.org>,
Alexander Viro <viro@zeniv.linux.org.uk>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
"Serge E. Hallyn" <serge@hallyn.com>,
Ingo Molnar <mingo@kernel.org>, Kees Cook <keescook@chromium.org>,
Mel Gorman <mgorman@suse.de>, Rik van Riel <riel@redhat.com>
Subject: Re: [PATCH] [RFC] mnt: restrict a number of "struct mnt"
Date: Tue, 18 Jun 2013 10:09:35 +0400 [thread overview]
Message-ID: <20130618060935.GA28077@gmail.com> (raw)
In-Reply-To: <20130617155614.f0c5b9458d4ff9372a05eaa0@linux-foundation.org>
On Mon, Jun 17, 2013 at 03:56:14PM -0700, Andrew Morton wrote:
> On Mon, 17 Jun 2013 12:58:00 -0700 ebiederm@xmission.com (Eric W. Biederman) wrote:
>
> > > I found that a few processes can eat all host memory and nobody can kill them.
> > > $ mount -t tmpfs xxx /mnt
> > > $ mount --make-shared /mnt
> > > $ for i in `seq 30`; do mount --bind /mnt `mktemp -d /mnt/test.XXXXXX` & done
> > >
> > > All this processes are unkillable, because they took i_mutex and waits
> > > namespace_lock.
> > >
> > > ...
> > > 21715 pts/0 ______D __________0:00 __________________\_ mount --bind /mnt /mnt/test.ht6jzO
> > > 21716 pts/0 ______D __________0:00 __________________\_ mount --bind /mnt /mnt/test.97K4mI
> > > 21717 pts/0 ______R __________0:01 __________________\_ mount --bind /mnt /mnt/test.gO2CD9
> > > ...
> > >
> > > Each of this process doubles a number of mounts, so at the end we will
> > > have about 2^32 mounts and the size of struct mnt is 256 bytes, so we
> > > need about 1TB of RAM.
> > >
> > > Another problem is that ___umount___ of a big tree is very hard operation
> > > and it requires a lot of time.
> > > E.g.:
> > > 16411
> > > umount("/tmp/xxx", MNT_DETACH) __________________= 0 <7.852066> (7.8 sec)
> > > 32795
> > > umount("/tmp/xxx", MNT_DETACH) __________________= 0 <34.485501> ( 34 sec)
> > >
> > > For all this time sys_umoun takes namespace_sem and vfsmount_lock...
> > >
> > > Due to all this reasons I suggest to restrict a number of mounts.
> > > Probably we can optimize this code in a future, but now this restriction
> > > can help.
> >
> > So for anyone seriously worried about this kind of thing in general we
> > already have the memory control group, which is quite capable of
> > limiting this kind of thing, and it limits all memory allocations not
> > just mount.
>
> What is the exposure here? By what means can a non-CAP_SYS_ADMIN user
> run sys_mount() under the namespace system?
>
> IOW, what does the sysadmin have to do to permit this? Is that a
> typical thing to do, or did the sysadmin make a mistake?
It's a problem for Linux Containers. Because usually the root user in
container should have enough rights to mount something (tmpfs,
bindmounts, etc). Our target is to make containers completely isolated.
A container is isolated with help of namespaces. The user namespace
creates a new sets of capabilities and users.
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2013-06-18 6:09 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-06-17 8:24 [PATCH] [RFC] mnt: restrict a number of "struct mnt" Andrey Vagin
2013-06-17 19:58 ` Eric W. Biederman
2013-06-17 22:56 ` Andrew Morton
2013-06-18 6:09 ` Andrew Vagin [this message]
2013-06-17 22:56 ` Andrey Wagin
2013-06-19 21:35 ` Andrey Wagin
2013-06-21 1:04 ` Eric W. Biederman
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=20130618060935.GA28077@gmail.com \
--to=avagin@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=avagin@openvz.org \
--cc=ebiederm@xmission.com \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mgorman@suse.de \
--cc=mingo@kernel.org \
--cc=riel@redhat.com \
--cc=serge@hallyn.com \
--cc=viro@zeniv.linux.org.uk \
/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.