[ On Friday, December 6, 2002 at 20:59:15 (-0600), David Young wrote: ]
> Subject: Re: Fork bomb protection patch
>
> I do not see how rlimits are sufficient to stop a fork bomb.

You can't ever really stop a fork bomb by just observing what's
happening from the kernel's point of view.  But that's not the point.
You don't need to.  There's nothing fundamentally different between a
fork-bomb and a valid set of processes that utilize all available and
authorised resources for some good purpose.

The point of rlimits is to impose fair limits on what a given user may
do with the system.  If a user chooses to run a fork-bomb then that's
fair and fine -- let them go to it until they get bored.

If several users collude to each do the same until the whole system is
unusable by anyone else then:  a) kick all offenders completely off the
system; and b) either adjust your limits or get more resources so that
it can't happen again.

>  RLIMIT_CPU
> applies to p_rtime, which a child does not inherit from its parent, so
> every fork() gives a fork bomb a new lease on life.  Also, RLIMIT_NPROC
> does not seem like sufficient protection: a bomb can use more than its
> "fair share" of resources without ever exceeding RLIMIT_NPROC. What am
> I missing?

No, a fork bomb cannot allow a user to use more than their fair share of
resources.  If you think that's happening then your rlimits are not set
correctly to match your expectations of fair use.

User rlimits have to be set such that the sum total of all possible
resources that can be used by a user don't adversely affect the system
and don't unfairly impact other users.

It is very difficult to calculate fair limits for a lot of users who
normally need to do quite a bit of computing with large and/or
long-running processes but who don't normally do stupid or malicious
things.  That's where management and operational controls come into the
picture.  Process accounting helps audit usage so that those external
controls can be justly applied.  It might be useful in such situations
if unix-like systems had realtime process accounting that supported
pre-paid accounts, such as Multics had.  I never dared even try a
fork-bomb on multics because my account never had enough funny-money in
it to pay for the experience (and those who exhausted their accounts
without having anything productive to show for it were not able to get
more funny-money for doing their assignments without serious begging or
actually buying time with reall $$$$).  However once my professors
trusted me not to do stupid or malicious things I was given access to
serious resources so that I could work with tools that would otherwise
have been unusable with the default student allocation (eg. writing code
in maclisp and using multics emacs to do so and to debug it).

-- 
								Greg A. Woods

+1 416 218-0098;            <g.a.woods@ieee.org>;           <woods@robohack.ca>
Planix, Inc. <woods@planix.com>; VE3TCP; Secrets of the Weird <woods@weird.com>