httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Johannes Erdfelt <>
Subject Re: trouble w/ perchild MPM
Date Wed, 27 Nov 2002 00:44:34 GMT
On Wed, Nov 27, 2002, James Ponder <> wrote:
> On Tue, Nov 26, 2002 at 07:06:33AM -0500, Jeff Trawick wrote:
> > Any debugging you can provide would be much appreciated.  perchild
> > is one of the potentially cool features of 2.0, but at the moment it
> I'm trying to understand perchild, so I've had a quick look at the source.
> Could you confirm my understanding?
> It appears that perchild starts by spawning processes, each process uses the
> inherited table to find out if it should change owner via setuid() and does so
> accordingly.  The children then spawn worker threads, all of those threads
> listen simultaneously, serialising on a cross-process mutex.  The first process
> that got this mutex accepts the connection, processes it until the post_read
> hook, passes it to another process if necessary via a named socket, and then
> longjmps out of the request so it can abort the connection processing itself.

That's how it currently is implemented.

> My questions are - why does worker use a listener thread, and perchild doesn't?

I suspect because it was originally thought it may not have been needed.
The existing implementation still has a design flaw where moving to a
listener thread model can help solve.

I'm currently in the process of implementing this.

> And secondly, surely allowing all these differently-owned processes access to
> the listening sockets means that any user with gdb can attach to their Apache
> process and intercept requests?  or am I missing the purpose of perchild?

That's a limitation of the existing implementation. Each child listens
on all sockets, even if it can't possibly answer a request for it. This
should be relatively easy to fix.

To answer your question about gdb, that is a configuration issue. Once
the code has been changed to not listen to all sockets, the security
implications are limited to sockets that the child is responsible for.
This can include shared (sometimes requiring connections to be passed)
and non shared (always answered by the child) sockets.

I don't particularly see the non shared case as a concern. The shared
case can be a problem.

If either are a problem, I suspect that perchild is not the MPM you want
to use.


View raw message