On 25/06/07, Steinar H. Gunderson <[EMAIL PROTECTED]> wrote:
On Mon, Jun 25, 2007 at 08:08:03PM +1000, Graham Dumpleton wrote:
> 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.
Yes, it is obviously an alternative, but FastCGI has its own sets of quirks,
and PHP under CGI too (as far as I know; I'm no PHP user).
Quirks such as? Am not asking to dispute that there aren't any, just
asking out of ignorance as to what they are so I can learn something.
Also, it won't
help you for anything that runs as a module; say, mod_dav_svn or mod_perl.
Various solutions to this problem have different tradeoffs -- among them
performance, security, complexity and applicability to different scenarios.
What mpm-itk gives you is a very simple solution that's one line per vhost
and works with a _lot_ of different use cases out of the box; I believe that
has a value in itself. Of course, I'd very much prefer a "real" perchild that
setuids before accepting the connection and then does connection passing, but
we're now several years (and at least SoC project) since the release of
Apache 2.0, and it doesn't really seem to be appearing anytime soon.
>> 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.
OK, then performance will suffer in this scenario.
And I think you will have similar problems with mod_perl as well given
that it relies to a degree on preloading and caching of Perl modules
as well.
BTW, for a different take on this whole problem you might have a look
at mod_wsgi (www.modwsgi.org). This only solves the problem for a
specific language, but it provides the choice of running a Python web
application embedded in the Apache child process (like mod_python), or
delegated to a daemon process (like mod_fastcgi). The mod_wsgi code
takes concepts such as process management from mod_cgid and proxying
of requests to the daemon process from mod_cgid and mod_scgi. Where it
is different to solutions like mod_scgi and mod_fastcgi though is that
the daemon process is a fork of the parent process, not a distinct
exec'd process. The daemon process then uses Apache/APR to construct
just enough of the normal Apache connection processing code to fake up
a request_rec and bucket chain, that way the exact same handler code
as would be used in the Apache child can be used.
Graham
