Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@httpd.apache.org
Date: Wed, 27 Nov 2002 00:35:09 +0000
From: James Ponder <james@squish.net>
To: dev@httpd.apache.org
Subject: Re: trouble w/ perchild MPM
Message-ID: <20021127003509.A16549@snowy.squish.net>
References: <20021126071452.GB333@metux.de>
 <m3u1i4y1py.fsf@rdu74-177-063.nc.rr.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <m3u1i4y1py.fsf@rdu74-177-063.nc.rr.com>;
 from trawick@attglobal.net on Tue, Nov 26, 2002 at 07:06:33AM -0500

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.

My questions are - why does worker use a listener thread, and perchild doesn't?
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?


Best wishes, James
-- 
James Ponder; www.squish.net; London, UK