httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Ponder <>
Subject Re: trouble w/ perchild MPM
Date Wed, 27 Nov 2002 01:41:14 GMT
On Tue, Nov 26, 2002 at 08:18:06PM -0500, Johannes Erdfelt wrote:
> > Perhaps perchild can be improved further to have a set of listener
> > processes/threads, under the generic apache user id or another secured id,
> > which accepts connections but does not process them.  These threads then
> > pass the connections on to the correct user-owned child id via the named
> > sockets, allowing these child users to have no listening sockets at all
> > (except the unix domain socket).
> It would need to be a process. Mixing uid's among threads is not
> portable.

I meant 1 or more processes with 1 or more threads each.  Has any work
been done on testing whether it's best to have 100 processes listening or
10 processes with 10 threads each all listening, or 10 processes with 10
threads each with one listener thread per process, etc. etc.?  I was
vague because I don't know best practice.

> Switching to a model like is possible, but I'm willing to be that
> passing fd's is not cheap and would just create overhead.

> Do you want to do this for security reasons?

Yes, I look after an Apache installation with hundreds of web sites, most
are name-based.  It's a shared infrastructure with dynamic content allowed,
in a single apache instance.  Within these parameters we try and make it
as secure as possible.  We can use unix-level system resource monitoring
for quite a lot of things, but having all content delivered by a single
user (the apache generic user) presents us with all sorts of problems, not
least of which is protecting that apache user from running user's code
(e.g. we use suexec, disallow execs in ssi, do not use things like mod_perl).

I'd like to ditch the current model of using suexec, to a perchild model.  If
there aren't other problems (perhaps other modules creating file descriptors)
then this would seem a sensible way forward, removing the need for suexec and
opening the possibility that we could offer dynamic content module providers
(mod_perl etc) in a secure way to our users.

Best wishes, James
James Ponder;; London, UK

View raw message