LWN: Comments on "Resource limits in user namespaces"

Resource limits in user namespaces

gutschke — Sun, 24 Jan 2021 18:55:17 +0000

Goats eat pretty much everything else. I don't see why they wouldn't eat tuna as well.

Resource limits in user namespaces

nix — Fri, 22 Jan 2021 17:05:48 +0000

There is at least one sheep farmer working on Linux stuff. It is mostly visible to the rest of us in increased annoyance around lambing time :)

Resource limits in user namespaces

nivedita76 — Wed, 20 Jan 2021 22:51:19 +0000

Agh, this article is very confusing. This patch does make the limits be per-namespace too, not just the counts?

Resource limits in user namespaces

nivedita76 — Wed, 20 Jan 2021 22:39:28 +0000

I'm confused. Isn't there only one RLIMIT_NPROC for a given process? i.e. I thought that the limits are per-process, and the counts, which used to be per-user are changing to per-user/per-namespace?

Counts v. limits

corbet — Tue, 19 Jan 2021 22:29:41 +0000

Ah right, that's the part I wasn't fully on top of. I've stuck an addendum onto the article.

Counts v. limits

ebiederm — Tue, 19 Jan 2021 22:06:19 +0000

The counts are not per process. The limits are per process.

That is starting with struct task_struct *task. The counts
for the problematic rlimits live in:

task->cred->user->{process, sigsigpending, mq_bytes, locked_vm}

The limits for the problematic rlimts live in:

task->signal->rlim[RLIMIT_NNNN];

Counts v. limits

corbet — Tue, 19 Jan 2021 21:56:27 +0000

Um....I thought the whole point of this exercise was that some limits are not per-process...? That's why a process in one container prevents the creation of a process in another? How can NPROC be per-process?

I'm clearly missing something here.

Counts v. limits

ebiederm — Tue, 19 Jan 2021 21:33:47 +0000

We are talking rlimits so the limits are fundamentally per-process.

What moving to ucounts does is it captures the per-process limit value at the
time of user namespace creation. Then when the counts are updated the
outer limit is checked, along with the per-process rlimit counts.

There is no need here for any root involvement.

``root'' can get involved if you want to modify the limits that were captured at user namespace creation. Those limits should be exposed as sysctls. In most cases
it should be safe to ignore them.

Resource limits in user namespaces

ebiederm — Tue, 19 Jan 2021 21:27:49 +0000

RLIMIT_NPROC is some large number in the parent namespace. So the limit check on the parent namespace passes. Only in the 2 containers is RLIMIT_NPROC == 1.

Resource limits in user namespaces

ebiederm — Tue, 19 Jan 2021 21:24:49 +0000

The problem statement for containers is make existing code work. So adding work-arounds for existing code is not a serious option.

Furthermore the example of a service setting RLIMIT_NPROC==1 while real
is just a motivating example. It shows how a process/container can legitimately tighten it's rlimits in a useful way, as well as being a case that is easy to see why it fails when that happens.

Resource limits in user namespaces

Cyberax — Tue, 19 Jan 2021 19:00:26 +0000

> In general, I'm pretty strongly against adding controllers for things which aren't fundamental resources in the system. What's next? Open files? Pipe buffer? Number of flocks? Number of session leaders or program groups?
Why not ALL of these?

This would at least unify all the various resource limits that currently exist in a kind of weird fashion.

Resource limits in user namespaces

nivedita76 — Tue, 19 Jan 2021 18:53:40 +0000

Hm I also don't get the fix. If the counts are hierarchical, why doesn't the setuid() call for the second run fail because there is already one process running for that user in the root namespace?

Resource limits in user namespaces

nivedita76 — Tue, 19 Jan 2021 18:07:21 +0000

I'm a little confused by the problem -- it seems to me that it is rather easy to work around for RLIMIT_NPROC == 1 case.

i.e. instead of launching the service by doing setrlimit() as root, then fork(), setuid(), execve(); can't you do fork(), setuid(), setrlimit(), execve()? This should be fine for the "prevent fork()" situation, no?

Counts v. limits

corbet — Tue, 19 Jan 2021 15:09:20 +0000

Yes, I guess I see why you need to change the count infrastructure. Where my confusion comes in is why the limits aren't made per-user-namespace as well. It seems that would create far more straightforward semantics and the possibility for control without root involvement.

Resource limits in user namespaces

pizza — Tue, 19 Jan 2021 13:35:55 +0000

> I have considerable experience* herding cats. How hard can it be to adapt to goats?

That depends; do goats like Tuna?

Resource limits in user namespaces

k3ninho — Tue, 19 Jan 2021 12:57:10 +0000

I have considerable experience* herding cats. How hard can it be to adapt to goats?

*: if not success

K3n. :-D

Resource limits in user namespaces

izbyshev — Tue, 19 Jan 2021 09:39:25 +0000

Yes, I wondered about that too while reading the article. Clearly, making counts per-user-namespace is a prerequisite for making resource limits per-user-namespace, so I don't understand why the article described the Gladkov's patchset as something orthogonal.

Resource limits in user namespaces

cyphar — Tue, 19 Jan 2021 06:59:03 +0000

Yes, ulimits are per-user but two processes with the same kuid in two different user namespaces (in other words, they map the to the same underlying user) will have the same limit because the limit is enforced per-kuid (it's not linked the user namespace you're in). This is a problem because some container runtimes reuse the same mapping for different containers, causing resource exhaustion between containers (and isolated containers a-la LXD have their own issues -- namely a fair number of programs expect to be able to create users with very large uids).

Resource limits in user namespaces

ebiederm — Tue, 19 Jan 2021 04:33:39 +0000

What was unclear about my reply?

If today the situation is that setting RLIMIT_NPROC == 1 and your service does not start, but it has nor processes in your user namespace. How can you possibly fix that without changing how the count works? AKA by making a per user per user_namespace count?

Resource limits in user namespaces

atai — Tue, 19 Jan 2021 03:42:50 +0000

managing goats--a big challenge

Resource limits in user namespaces

gus3 — Tue, 19 Jan 2021 03:11:24 +0000

Until the goat smacks your bum with its forehead and knocks you into the watering trough.

Resource limits in user namespaces

johannbg — Mon, 18 Jan 2021 21:11:30 +0000

Let's all take a deep breath and considers a career change to goat farming. What a simple life it would be...

Resource limits in user namespaces

nickodell — Mon, 18 Jan 2021 20:31:00 +0000

ulimit supports per-user process limits, right? Is there some reason why you couldn't create a user namespace, and set two process limits on two users within that namespace?