httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Graham Dumpleton" <>
Subject Re: Inclusion of mpm-itk into HEAD
Date Mon, 25 Jun 2007 10:08:03 GMT
On 25/06/07, Steinar H. Gunderson <> wrote:
> On Mon, Jun 25, 2007 at 02:36:41PM +1000, Graham Dumpleton wrote:
> > What specific applications are you running that require things to be
> > run as a distinct user? Are these applications implemented directly in
> > C as custom Apache modules, or are you writing stuff in other
> > languages, ie., such as PHP, Perl, running under mod_php or mod_perl?
> > What are the perceived reasons that solutions such as mod_fastcgi,
> > mod_scgi or the various mod_proxy type solutions wouldn't be a viable
> > alternative for hosting your application?
> The main point is separating the vhosts better from each other. Think of your
> typical PHP application, doing something along the lines of
>   /srv/vhost1/database.php:
>   $conn = pg_connect("blablabla", "username", "mysupersecretpassword");
> Now, since database.php must be readable by www-data, a different user on the
> same server could write something along the lines of:
>   /srv/vhost2/evil.php:
>   passthru("cat /srv/vhost1/database.php");
> and get the password.
> There are various ways of trying to taper over this in the programming
> language (such as PHP), but they all have their disadvantages, and they don't
> apply to other languages, .htaccess/.htpasswd files, static files, etc.. This
> is the specific scenario that mpm-itk is designed to resolve, and it seems to
> be a very real problem in a rather large number of real installations.

Or you can use PHP under fastcgi. With fastcgi the code would run in a
separate process and you could have any number of processes
corresponding to whatever virtual hosts you have. Because it is a
separate process it can run from the outset as whatever user you want
thus avoiding any danger points where code would be run as root.

> > For mod_python based Python applications such as Django and
> > TurboGears, which have a memory footprint starting at about 7MB and
> > 15MB respectively, any performance loss would not 'just disappear in
> > the equation" as the load time for each request would be significant
> > given that process would be thrown away after each request and
> > everything would need to be reloaded.
> Doesn't mod_python load these up-front, so they'd be available before the
> fork?

No. The only thing which is done before the fork is the initialisation
of the Python interpreter. It isn't safe to do anything more than that
as the parent process runs as root.


View raw message