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

From: Giulio Picierro <>
Date: Mon, 25 Jan 2021 14:17:17 +0100

Dear Laslo,

sorry for the late reply, I had a really busy week (course to teach) :/.

I didn't have the chance to test the new code, which I will do soon,

If I understand correctly your solution is to read the rlimit from the
system and then update accordingly.

Now it seems to me a good solution, however I have to ask: do we really
need to set the rlimit on the number of processes (which are fixed)?

I mean, what is the rationale behind it? Security purposes?

I'm just asking out of curiosity, to understand better the design
choices :D.

Thank you,


On 1/21/21 1:18 AM, Laslo Hunhold wrote:
> On Mon, 18 Jan 2021 23:03:11 +0100
> Laslo Hunhold <> wrote:
>> 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.
> To give a followup, I went with option 2), because it allows the
> smoothest operation. Quark is run as root and thus can seize all the
> assets it needs. I'm sure many set their global resource limits to
> reasonable values, but if you run your server and give it a thread and
> slot count, you can estimate that it might exceed your resources. In
> that respect, it is forgivable by quark to just raise the bar instead
> of failing.
> Thanks again, Giulio, for your input and patch suggestion. I hope this
> fixes your issues in your case!
> With best regards
> Laslo
Received on Mon Jan 25 2021 - 14:17:17 CET

This archive was generated by hypermail 2.3.0 : Mon Jan 25 2021 - 14:48:39 CET