Re: [hackers] [quark][PATCH] Add a config switch to enable/disable NPROC limit

From: Laslo Hunhold <dev_AT_frign.de>
Date: Mon, 18 Jan 2021 23:03:11 +0100

On Sun, 17 Jan 2021 17:29:53 +0100
Giulio Picierro <giulio.picierro_AT_uniroma2.it> wrote:

Dear Giulio,

> Quoting the book "The Linux Programming Interface" from Micheal
> Kerrisk: "the RLIMIT_NPROC limit, which places a limit on the number
> of processes that can be created, is measured against not just that
> process’s consumption of the corresponding resource, but also against
> the sum of resources consumed by all processes with the same real
> user ID."
>
> This leads quark to easily fail on Linux when launched with the same
> userid of a logged user.
>
> For example if the user 'giulio' has an active desktop session, the
> following command:
>
> $ sudo ./quark -p 8080 -u giulio -g giulio -l
>
> fails with the following error:
>
> $ ./quark: pthread_create: Resource temporarily unavailable
>
> No error occour if instead quark is launched with an userid that does
> not have a session, such as the 'http' user, usually reserved for web
> servers.
>
> I don't know if this is expected or this could be considered a bug:
> in the end for production servers we could expect that the limit
> works correctly.
>
> In any case, the least invasive way that I have found to solve the
> issue is to introduce a config switch to disable the limit, retaining
> it enabled by default.

that is a really nice observation! Thanks for pointing it out and your
elaborate explanation. I must honestly admit that I assumed the limit
was per process and not per user. I'll think about how to approach this
the best way; given your aforementioned fact, I only see two options:

   1) Don't touch the rlimits and let it fail, giving a proper error
      message (might be problematic for open file descriptors that
      might get exhausted at runtime). One can also check the limits
      beforehand and error out (e.g. if we cannot guarantee 4 fds per
      slot).
   2) Uncrement the rlimits by first reading them and setting the
      incremented value. possible problems here are TOCTOU (even though
      the risk here is not too high) and a possible interference in
      things that shouldn't be touched by convention.

What do the others think?

With best regards

Laslo
Received on Mon Jan 18 2021 - 23:03:11 CET