Re: [RFC PATCH] rlimit: Account nproc per-usernamespace/per-user

[ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org (Eric W. Biederman)]

Nikolay Borisov <kernel-6AxghH7DbtA@public.gmane.org> writes:

> On 11/01/2016 05:01 PM, Eric W. Biederman wrote:

>> I think conceptually this can work.
>> 
>> Reading through the code I don't see anything capturing the current
>> processes RLIMIT_NPROC when creating a new user namespace.  Which is
>> critical if the limits are going to be enforced hierarchically.
>
> Right, now the question is whether the limits can in fact be enforced
> hierarchically. Because what's really happening is that the actual limit
> is set per-process (in task->signal->rlim[limit].rlim_cur). However, the
> signal struct is being copied when we fork a new process.
>
> With such a setup nothing prevents the parent process to die and thus
> loosing the hierarchical relationship.  Otherwise a rework would need to
> be done to move the rlimits in the struct user_namespace. Essentially
> this is an open problem and it would require some more design thinking
> to get it right.

The only point I see in using the ucount infrastructure is if we limit a
user namespace to the number of processes the creator of user namespace
was allowed to create.  Thus making it impossible to escape your limit
by creating a user namespace and using multiple users.

Your current patch achieves the opposite.  Making it even easier to
escape your current rlimit which is a regression and unacceptable.

>> 
>> I have a small concern that we toss the per user accounting entirely as
>> that means we loose a little in ensuring one uid does not have too many
>> processes.  But that is comparatively minor.
>> 
>> I am buried with Kernel Summit and Plumbers this week, so I will be slow
>> on review etc.
>> 
>> But overall I think this a viable approach assuming there are no
>> performance issues in structuring things this way.
>
> According to my experiments (see reply I sent to Serge) ucount doesn't
> introduce major performance bottlenecks. If you have ideas for a
> particular usecases worth investigating I'm happy to do it. But plain
> old forking should be sufficient.

Which is nice but you have only measured half of what is interesting.
Until there is hierarchical limit enforcement this is uninteresting.

Eric