On Fri, 21 Jan 2000, Doug White wrote:
> On Thu, 20 Jan 2000, Matthew Reimer wrote:
> > Background: in an attempt to manage our webserver to keep too many CGIs
> > from taking down the machine, I've been experimenting with RLIMIT_NPROC.
> > This appears to work fine when forking new processes, causing the fork
> > to fail with error EAGAIN.
> >
> > However, this didn't solve our problem. We're using Apache with suexec,
> > and still CGIs would multiply far beyond the specified resource limit.
> >
> > Apache forks suexec, which is suid root; fork1() increments the number
> > of processes for root, unless RLIMIT_NPROC has been exceeded, in which
> > case the fork fails with EAGAIN.
> >
> > suexec calls then calls setuid() (before it calls execv), which
> > decrements root's process count and increments the target user's process
> > count, but RLIMIT_NPROC is not consulted, and voila, we've just exceeded
> > the target user's maximum process count.
I was considering this same problem a few nights ago.
My solution, (which was more to prevent a forkbomb-via-network) is to just
restrict the maximum number of connections to something reasonable.
As long as your cgis spawn a predictable number of subprocesses (say,
NPROC), you can usually guesstimate that if you want no more than 100
processes:
MAX_CONNECTIONS * NPROC = 100
Of course, if they're not at all predictable, that sucks.
I'd probably try exploring running apache as a specific user (binding
it to port say, 8080) and letting old fashioned UNIX limits kick in. You'd
be avoiding suexec because it'd already be running at the desired
userlevel.
Authbind might be worth pursuing, except:
a> I only know of it via hearsay
b> It might be Linux only
If that didn't work, I'd consider Linux and hope capabilities were
implemented.
It seems awkward that such a simple concept is such a pain in the ass to
implement in bullet-proof fashion. Welcome to UNIX :)
-MB
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
