Re: [PATCH] bringing down the server from an MPM thread

[Scott Hess <sc...@avantgo.com>]

It would seem that the appropriate action would be for the child to signal
a problem, and then the parent to double-check the problem - or, for the
parent to run a poll() on all of the listen sockets before spinning up a
new child.  Perhaps the double-check code can run only when the child
didn't service any requests before exitting (though it shouldn't be
expensive enough to warrant that).

I'm also less than comfortable with having the child manage to kill the
parent.  Since the parent runs as root, and the child runs as nobody, it's
a potential security hole.  Convincing the OS to screw the listen socket
is hopefully much harder than convincing an Apache child to return a
server-should-exit code.

Later,
scott

On 26 Jul 2000, Jeff Trawick wrote:
> The example problem I'm trying to solve now:
> 
> Currently, when I stop the the TCP/IP stack on OS/390 and Apache starts
> getting errors from poll() and accept(), it tries to keep going,
> consuming lots of CPU because poll() and accept() return immediately
> with failure.  Listening sockets are toast and can never be used
> successfully again, and we need to clear out.  Just exiting the child
> process doesn't improve anything; it just gets the parent to fork()
> again (unless it gets the magic exit status).
> 
> Even if the suggestion described in the ENETDOWN comment was
> implemented, worker threads would have to do something to cause the
> child processes to be exited in a way that told the parent process to
> bring down any remaining children and back up to a certain part of
> initialization, perhaps retrying the initialization of listening
> sockets until it worked again.

Re: [PATCH] bringing down the server from an MPM thread

[Jeff Trawick <tr...@bellsouth.net>]

Scott Hess <sc...@avantgo.com> writes:

> It would seem that the appropriate action would be for the child to signal
> a problem, and then the parent to double-check the problem - or, for the
> parent to run a poll() on all of the listen sockets before spinning up a
> new child.  Perhaps the double-check code can run only when the child
> didn't service any requests before exitting (though it shouldn't be
> expensive enough to warrant that).

I think it is a fine idea for the parent to test all of the listening
sockets.  At least on OS/390, a simple getsockopt(,SO_ERROR,) will
detect the error I'm trying to catch.  I'll use this idea in my next
patch. 

> 
> I'm also less than comfortable with having the child manage to kill the
> parent.  Since the parent runs as root, and the child runs as nobody, it's
> a potential security hole.  Convincing the OS to screw the listen socket
> is hopefully much harder than convincing an Apache child to return a
> server-should-exit code.

Bad/malicious code in apache core or a plug-in module running in the child
process can easily create other DOS attacks (consume resources, cause
requests to hang, segfault over and over, etc.).  It is hard for me to
imagine Apache core doing much to defend against this.  If the
administrator wants to load m0d_d0s into her production Apache, she
is on her own.

Have fun,

Jeff
-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

--PAE27060.965417813/adsl-77-240-89.rdu.bellsouth.net--