Subject: Re: Fork bomb protection patch (Was: Re: CVS commit: syssrc/sys/kern)
To: Roland Dowdeswell <elric@imrryr.org>
From: Jaromir Dolecek <jdolecek@netbsd.org>
List: tech-kern
Date: 12/08/2002 21:51:01
Roland Dowdeswell wrote:
> I do not buy this, and have presented one example where this is
> not the case.  thttpd neither busy loops on fork(), nor exits on
> fork() failure.  I am guessing that inetd, sshd, etc. probably fall
> into the same boat of neither busy-looping nor exiting.

Yes, I realized this when I actually checked what thttpd does.
It logs the error condition, returns error to client and proceeds
to next request. So, no busy loop, just return failure. This is
indeed what daemons generally do.

You are also right that e.g. inetd is in the same boat, tho IIRC
inetd does some connection throttling (allows only 100 per second?).

> The reason
> that I chose thttpd off the top of my head was that it is a program
> that performs work in a hybrid event-driven/fork model and hence
> it is easy to see that arbitrarily enforced sleeps will cause it
> to behave in unexpected fashions.  I am sure that there are other
> examples.

I guess it's arguable what's the best behaviour in overload condition.

I agree that thttpd 'no more CGI if cannot fork' is about as
sensible as it can get. Since it doesn't fork for static pages, this
works fine for it.
OTOH, it still seems to be not right that thttpd would spawn
potentially unbound number of children with no way to control
the number besides resource limits.

Jaromir
-- 
Jaromir Dolecek <jdolecek@NetBSD.org>            http://www.NetBSD.org/
-=- We should be mindful of the potential goal, but as the tantric    -=-
-=- Buddhist masters say, ``You may notice during meditation that you -=-
-=- sometimes levitate or glow.   Do not let this distract you.''     -=-