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]
Message-ID: <20111103185108.GA5153@Debian-60-squeeze-64-minimal>
Date:	Thu, 3 Nov 2011 19:51:08 +0100
From:	Max Kellermann <max@...mpel.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Glauber Costa <glommer@...allels.com>,
	linux-kernel@...r.kernel.org,
	containers@...ts.linux-foundation.org,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: [PATCH] new cgroup controller "fork"

On 2011/11/03 19:21, Alan Cox <alan@...rguk.ukuu.org.uk> wrote:
> > After little discussion, nobody seemed to be interested in it, and
> > nobody merged it.  I reposted it today, not knowing somebody else had
> > come up with a similar idea meanwhile.
> 
> I don't really see a meaningful use case for this. Why should millions of
> users have this stuff in their kernel. What's the general purpose use
> case we should all be excited about ?

Putting a reasonable limit on jobs that are expected to run only for a
limited amount of time, with a limited amount of total resources.  For
example: CGI, cron jobs, backup, munin plugins, virus scanners and
other email filters, procmail, ... - when the job is done, the group
can be deleted, and new instances will run in a new group.

With just RLIMIT_NPROC or task_counter, you can limit the total number
of processes, but it will not stop a fork bomb - it will only slow it
down.  The fork bomb will still bounce between 1 and the limit, and
consume lots of resources for forking and exiting.

(Glauber: the above should answer your last email, too)

Similar existing feature: RLIMIT_CPU.  Millions of users have it in
their kernels, but nobody uses it nowadays.  And it's not even
optional.

Btw. I have no problem with maintaining this patch (and a whole bunch
of others) in my proprietary git repository at work forever.  They're
very useful for my employer.  I'm just trying to be a good citizen by
sharing them.

Max
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ