httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <wr...@rowe-clan.net>
Subject Re: Inclusion of mpm-itk into HEAD
Date Mon, 25 Jun 2007 16:06:11 GMT
Nick Kew wrote:
> "Steinar H. Gunderson" <sgunderson@bigfoot.com> wrote:
> 
>>  - setuid() happens after the request has been parsed, which means
>> that the server runs as root up until that point. (However, on a
>> system with capabilities, ie. Linux 2.6, almost all superuser
>> privileges are dropped, so you can't just load kernel code or
>> whatever.)
> 
> First there's the obvious issue of any bugs in the core code
> (which includes yours - if it goes in) going nuclear by running
> as root.
> 
> But secondly, it does the same for a lot of module code.  Any
> module that runs a connection-level input filter, such as SSL,
> a protocol module, or a bandwidth-shaping module, is going to
> have code run as root.  That means a lot of existing third-party
> code goes nuclear too.  Including it in the core dist makes a
> huge target!  People get pwned, apache gets the blame.

This has been a design constraint from the very early days, which is why
I expect your MPM would not be included in the core distribution.  We
have a very similar issue (to be solved differently) in mod_ftp, when the
user insists that the data port must be bound to a low #'ed (traditional)
ftp data port.  Defining a block of high numbered ports through the router
is the suggested way to go.

That said, have you considered a design where there are separate pools
of processes per-user, and these would be dispatched after the headers
are processed to the appropriate child?

Of course, this brings us back to perchild which has been longing for
some time for more attention.  But that said - your module does offer
something to compliment perchild for users of thread-unsafe module
designs, and provides the process separation that some admins desire.

Bill


Mime
View raw message