Subject: Re: Fork bomb protection patch
To: None <tech-kern@netbsd.org>
From: David Young <dyoung@ojctech.com>
List: tech-kern
Date: 12/07/2002 01:52:03
On Sat, Dec 07, 2002 at 01:00:32AM -0500, Thor Lancelot Simon wrote:
> What you're missing is that the cpu time limit prevents any single process
> from using more than a given amount of CPU time -- whether looping around
> a system call that fails or not -- and the processes limit will prevent
> any user from creating more than a given number of processes.
But, but....
> Mind you, if one instance of the forkmonster dies because it's managed to
> run up to its CPU time limit, another will manage to fork -- once. But the
> CPU time limit is useful for preventing runaway processes from looping around
> system calls that do not spawn children, which is hardly uncommon.
That's what I thought: RLIMIT_CPU * RLIMIT_NPROC is not the limit on
the number of CPU seconds that a fork bomb can consume in its lifetime.
A fork bomb may consume many times the RLIMIT_CPU of any single process
constituting the bomb---infinitely many times, really. The bomb need
only fork one process for every process that hits its CPU time limit,
and it will go forever. I don't like that at all. =)
> In practice, users on timesharing systems seldom need more than 10 or 15
> simultaneous processes -- in fact, often less than that number will
> suffice. Even with the default per-user process limit -- which, I would
> contend, is set far too high at 160; it never used to be that high and
> I do not believe that it should be that high now -- it's possible for the
> superuser to clean things up easily enough, though the system will slow to
> a crawl while he's doing so. The ultimate solution lies in cleaning up the
> users in question, if they're malicious or stupid enough to keep running
> forkmonsters.
Ok. Is it fair to say that we both believe in the Law, but I prefer
that the Law is the Law of Physics (CPU seconds can neither be created
nor destroyed) and you prefer that the Law is the Law of the Sysadmin
(don't get caught cheating on your CPU seconds) ? There are pros and
cons for each.
> Furthermore, I suggest that the incompetence of the average modern system
> administrator and his unwillingness to consider the appropriate resource
> limits for users of his system as well as to learn or build the simple tools
> he needs to deal with users who misbehave are really no good reason to do
> dumb things like make system calls mysteriously sleep for half a second to
> deal with broken or evil programs that loop around them.
I agree that things should not be dumbed down. I would like to see
things "smartened up," with something akin to either a revocable
fork/run capability, %CPU limits, or both.
Dave
--
David Young OJC Technologies
dyoung@ojctech.com Engineering from the Right Brain
Urbana, IL * (217) 278-3933