Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1411879

Re: [RFC PATCH 0/4] Make inotify instance/watches be accounted per userns

From Nikolay Borisov <kernel@kyup.com>
Newsgroups linux.kernel
Subject Re: [RFC PATCH 0/4] Make inotify instance/watches be accounted per userns
Date 2016-06-02 08:30 +0200
Message-ID <rFuiK-2lh-13@gated-at.bofh.it> (permalink)
References <rF9ei-5BV-11@gated-at.bofh.it> <rFh29-2cp-5@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw



On 06/01/2016 07:00 PM, 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.

This is indeed a problem and the presented solution is rather dumb in
that regard. I'm happy to work with you on suggestions so that I arrive
at a solution that is upstreamable.

> 
> 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?

Loose limits.

> 
> Are these tight limits to ensure multitasking is possible?
> 
> 
> 
> For tight limits where something is actively controlling the limits you
> probably want a cgroup base solution.
> 
> For loose limits that are the kind where you set a good default and
> forget about I think a user namespace based solution is reasonable.

That's exactly the use case I had in mind.

> 
>> The solution I propose is rather simple, instead of accounting the 
>> watches/instances per user_struct, start accounting them in a hashtable, 
>> where the index used is the hashed pointer of the userns. This way
>> the administrator needn't set the inotify limits very high and also 
>> the risk of one container breaching the limits and affecting every 
>> other container is alleviated.
> 
> I don't think this is the right data structure for a user namespace
> based solution, at least in part because it does not account for users
> escaping.

Admittedly this is a naive solution, what are you ideas on something
which achieves my initial aim of having limits per users, yet not
allowing them to just create another namespace and escape them. The
current namespace code has a hard-coded limit of 32 for nesting user
namespaces. So currently at the worst case one can escape the limits up
to 32 * current_limits.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[RFC PATCH 0/4] Make inotify instance/watches be accounted per userns Nikolay Borisov <kernel@kyup.com> - 2016-06-01 10:00 +0200
  [PATCH 2/4] inotify: Convert inotify limits to be accounted per-realuser/per-namespace Nikolay Borisov <kernel@kyup.com> - 2016-06-01 10:00 +0200
  [PATCH 1/4] inotify: Add infrastructure to account inotify limits per-namespace Nikolay Borisov <kernel@kyup.com> - 2016-06-01 10:00 +0200
    Re: [PATCH 1/4] inotify: Add infrastructure to account inotify  limits per-namespace Cyrill Gorcunov <gorcunov@gmail.com> - 2016-06-06 10:10 +0200
      Re: [PATCH 1/4] inotify: Add infrastructure to account inotify limits  per-namespace Nikolay Borisov <kernel@kyup.com> - 2016-06-06 11:30 +0200
  [PATCH 4/4] inotify: Don't include inotify.h when !CONFIG_INOTIFY_USER Nikolay Borisov <kernel@kyup.com> - 2016-06-01 10:00 +0200
  [PATCH 3/4] misc: Rename the HASH_SIZE macro Nikolay Borisov <kernel@kyup.com> - 2016-06-01 10:00 +0200
    Re: [PATCH 3/4] misc: Rename the HASH_SIZE macro David Miller <davem@davemloft.net> - 2016-06-01 20:20 +0200
  Re: [RFC PATCH 0/4] Make inotify instance/watches be accounted per userns ebiederm@xmission.com (Eric W. Biederman) - 2016-06-01 18:20 +0200
    Re: [RFC PATCH 0/4] Make inotify instance/watches be accounted per  userns Nikolay Borisov <kernel@kyup.com> - 2016-06-02 08:30 +0200
      Re: [RFC PATCH 0/4] Make inotify instance/watches be accounted per userns ebiederm@xmission.com (Eric W. Biederman) - 2016-06-02 18:40 +0200
    Re: [RFC PATCH 0/4] Make inotify instance/watches be accounted per  userns Jan Kara <jack@suse.cz> - 2016-06-02 09:50 +0200
      Re: [RFC PATCH 0/4] Make inotify instance/watches be accounted per userns ebiederm@xmission.com (Eric W. Biederman) - 2016-06-02 19:20 +0200
        Re: [RFC PATCH 0/4] Make inotify instance/watches be accounted per  userns Nikolay Borisov <kernel@kyup.com> - 2016-06-03 13:20 +0200
          Re: [RFC PATCH 0/4] Make inotify instance/watches be accounted per userns ebiederm@xmission.com (Eric W. Biederman) - 2016-06-03 23:00 +0200
            Re: [RFC PATCH 0/4] Make inotify instance/watches be accounted per  userns Nikolay Borisov <kernel@kyup.com> - 2016-06-06 08:50 +0200
              Re: [RFC PATCH 0/4] Make inotify instance/watches be accounted per userns ebiederm@xmission.com (Eric W. Biederman) - 2016-06-06 22:20 +0200

csiph-web