From: Jan Kara <jack@suse.cz>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Nikolay Borisov <kernel@kyup.com>,
john@johnmccutchan.com, eparis@redhat.com, jack@suse.cz,
linux-kernel@vger.kernel.org, gorcunov@openvz.org,
avagin@openvz.org, netdev@vger.kernel.org,
operations@siteground.com,
Linux Containers <containers@lists.linux-foundation.org>
Subject: Re: [RFC PATCH 0/4] Make inotify instance/watches be accounted per userns
Date: Thu, 2 Jun 2016 09:49:20 +0200 [thread overview]
Message-ID: <20160602074920.GG19636@quack2.suse.cz> (raw)
In-Reply-To: <8737ow7vcp.fsf@x220.int.ebiederm.org>
On Wed 01-06-16 11:00:06, Eric W. Biederman wrote:
> Cc'd the containers list.
>
> Nikolay Borisov <kernel@kyup.com> writes:
>
> > Currently the inotify instances/watches are being accounted in the
> > user_struct structure. This means that in setups where multiple
> > users in unprivileged containers map to the same underlying
> > real user (e.g. user_struct) the inotify limits are going to be
> > shared as well which can lead to unplesantries. This is a problem
> > since any user inside any of the containers can potentially exhaust
> > the instance/watches limit which in turn might prevent certain
> > services from other containers from starting.
>
> On a high level this is a bit problematic as it appears to escapes the
> current limits and allows anyone creating a user namespace to have their
> own fresh set of limits. Given that anyone should be able to create a
> user namespace whenever they feel like escaping limits is a problem.
> That however is solvable.
>
> A practical question. What kind of limits are we looking at here?
>
> Are these loose limits for detecting buggy programs that have gone
> off their rails?
>
> Are these tight limits to ensure multitasking is possible?
The original motivation for these limits is to limit resource usage. There
is in-kernel data structure that is associated with each notification mark
you create and we don't want users to be able to DoS the system by creating
too many of them. Thus we limit number of notification marks for each user.
There is also a limit on the number of notification instances - those are
naturally limited by the number of open file descriptors but admin may want
to limit them more...
So cgroups would be probably the best fit for this but I'm not sure whether
it is not an overkill...
Honza
--
Jan Kara <jack@suse.com>
SUSE Labs, CR
next prev parent reply other threads:[~2016-06-02 7:49 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-06-01 7:52 [RFC PATCH 0/4] Make inotify instance/watches be accounted per userns Nikolay Borisov
2016-06-01 7:52 ` [PATCH 1/4] inotify: Add infrastructure to account inotify limits per-namespace Nikolay Borisov
2016-06-06 8:05 ` Cyrill Gorcunov
2016-06-06 9:26 ` Nikolay Borisov
2016-06-01 7:52 ` [PATCH 2/4] inotify: Convert inotify limits to be accounted per-realuser/per-namespace Nikolay Borisov
2016-06-01 7:52 ` [PATCH 3/4] misc: Rename the HASH_SIZE macro Nikolay Borisov
2016-06-01 18:13 ` David Miller
2016-06-01 7:53 ` [PATCH 4/4] inotify: Don't include inotify.h when !CONFIG_INOTIFY_USER Nikolay Borisov
2016-06-01 16:00 ` [RFC PATCH 0/4] Make inotify instance/watches be accounted per userns Eric W. Biederman
2016-06-02 6:27 ` Nikolay Borisov
2016-06-02 16:19 ` Eric W. Biederman
2016-06-02 7:49 ` Jan Kara [this message]
2016-06-02 16:58 ` Eric W. Biederman
2016-06-03 11:14 ` Nikolay Borisov
2016-06-03 20:41 ` Eric W. Biederman
2016-06-06 6:41 ` Nikolay Borisov
2016-06-06 20:00 ` 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=20160602074920.GG19636@quack2.suse.cz \
--to=jack@suse.cz \
--cc=avagin@openvz.org \
--cc=containers@lists.linux-foundation.org \
--cc=ebiederm@xmission.com \
--cc=eparis@redhat.com \
--cc=gorcunov@openvz.org \
--cc=john@johnmccutchan.com \
--cc=kernel@kyup.com \
--cc=linux-kernel@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=operations@siteground.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;
as well as URLs for NNTP newsgroup(s).