httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steinar H. Gunderson" <>
Subject Re: Inclusion of mpm-itk into HEAD
Date Mon, 25 Jun 2007 10:04:14 GMT
On Mon, Jun 25, 2007 at 09:20:45AM +0100, Nick Kew wrote:
>>  - mpm-itk is in production use at several sites -- for instance,
> Isn't that also true of metux?

I don't know. Can you point me to any sites? Does Metux even support SSL yet?

> That looks like a serious problem to me.
> 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.
> For example, it looks a lot like a case of
> 	itk + slapper = remote root

Well, there's a tradeoff here. First of all, note that mpm-itk runs with a
very limited set of root capabilities on platforms (ie. Linux 2.6) where this
is possible; you cannot, for instance load new kernel code, you'd have to
setuid to a different user and hope that that user has enough privileges to
spoof yourself back into root directly or indirectly somehow. Second, you need
to balance this potential issue against the issue the code solves in the
first place (as mentioned in my other e-mail, the fact that different vhosts
have full read access to each others' files).

Given that the potential damage is large but risk is relatively low (when did
Apache core last have an remote-exploitable bug like this?), and the problem
we're protecting against has a medium damage and happens every day, I think the
admin should ultimately be the one to decide whether this is a good tradeoff
or not. We should of course be very clear on what the advantages and
disadvantages are, but IMNSHO (being the author :-) ) the choice should be

> So you've introduced something that looks much the same as the
> traditional "CGI overhead", but applied it to every request instead
> of just CGI?

Every single _connection_, but yes.

> How does it offer any advantage over CGI+suexec?
> Not to mention its variants like fastcgi?

It works with PHP (without having to run PHP as CGI, which has its own
different sets of kludges). It works with mod_perl applications. It works
with mod_dav_svn. It handles static files exactly the same as it handles
dynamic files. It is extremely simple to set up, and rather difficult to set
up wrong.

By the way, I seem to have forgotten in my last post to mention that mpm-itk
is also in Mandriva Linux. Sorry for leaving you out :-)

/* Steinar */

View raw message