linux-kernel - Re: [PATCH] new cgroup controller "fork"

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Thu, 3 Nov 2011 16:34:57 -0200
From:	Glauber Costa <glommer@...allels.com>
To:	Max Kellermann <mk@...all.com>
CC:	Frederic Weisbecker <fweisbec@...il.com>,
	Tim Hockin <thockin@...kin.org>,
	<containers@...ts.linux-foundation.org>,
	<linux-kernel@...r.kernel.org>,
	Johannes Weiner <hannes@...xchg.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH] new cgroup controller "fork"

On 11/03/2011 04:30 PM, Max Kellermann wrote:
> On 2011/11/03 18:50, Glauber Costa<glommer@...allels.com>  wrote:
>> That still seems to be up to admin. If no processes are removed from
>> the cgroup or included in the cgroup, the only action/verb the
>> counter
>> is concerned about is to fork. Under this circumstance, both seem
>> equivalent from my PoV.
>
> I'm confused.  One of us misunderstands the whole thing.
>
> Examples of both controllers:
>
> task_counter: task.limit=2.  Let's say the only process in that group
> forks, then you have two processes.  Forking is disallowed from now
> on.  The child process exits, and there's only one left - which is
> allowed to fork!  The group may bounce between 0 and 2 processes
> forever.

Ah, I see. I assumed you were decrementing the counter when a process 
exited.

> cgroup_fork: fork.remaining=2.  Now let's say we have one thousand
> processes in that group!  One of those forks (allowed).  And it forks
> again (allowed).  And tries again - blocked because "fork.remaining"
> has reached zero.  We have 1002 processes; when 1001 of those
> processes exit, one remains, but it is still disallowed to fork,
> because "fork.remaining" is still zero.  It will remaing zero until
> somebody with write permissions raises it again.
>
> Did I get it wrong?  To me, that is not look equivalent at all.
No, I was not careful enough when reading the patch, and as already 
stated, I made an assumption that seemed reasonable.

Which raises the question: If you don't decrement on exit, and only 
count how many forks happened in the past, what is your use case for this?

Please note that both of you seem to target the same goal: prevent fork 
bombs. If a child exits, I see no reason to not open up room for a new 
process inside the group.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/