Thor,

I do not see how rlimits are sufficient to stop a fork bomb. 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?

Dave

On Fri, Dec 06, 2002 at 08:48:42PM -0500, Thor Lancelot Simon wrote:
> On Fri, Dec 06, 2002 at 05:29:38PM -0800, Bill Studenmund wrote:
> > On Sat, 7 Dec 2002, Daniel Carosone wrote:
> > 
> > > On Fri, Dec 06, 2002 at 06:49:32PM -0500, Lord Isildur wrote:
> > > > exactly. stop 'em first so they cant keep forking, and then pick them off
> > > > at your leisure.
> > >
> > > Pardon me - isn't that what the sleep part of this change does for you?
> > 
> > Yes and no.
> > 
> > While the sleep part will do that, you don't need the sleep part to
> > achieve it.
> 
> Furthermore, it's trivial to avoid ever hitting the sleep, with about ten
> seconds of thought.  Get the processes rlimit before you start forking, and
> use IPC via pipes or a shared memory segment (e.g. one shared by related
> processes using mmap()) to control who can fork when.  Between forks,
> just do random fast system calls to eat CPU.
> 
> In other words, this change is not *sufficient* to stop even a trivial
> deliberate attack on the system, while it is not *necessary* to stop
> accidental forkmonsters from eating all system resources -- rlimit and
> kill work quite nicely for that already.  It is a poor idea and should
> never have been committed to our tree.
> 
> Thor

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Engineering from the Right Brain
                        Urbana, IL * (217) 278-3933