[webapps] PHP files owner

Tomasz Pala gotar at polanet.pl
Wed Jun 13 10:14:47 CEST 2007


On Wed, Jun 13, 2007 at 09:19:10AM +0200, Jacek Konieczny wrote:
> On Wed, Jun 13, 2007 at 01:52:01AM +0200, Tomasz Pala wrote:
> > - PHP as CGI run via suexec - performance penalty, but the only one solution
> >   solving problem of inherited EUID for exec(), system() etc.
> 
> There is also another one, safe and easy solution: PHP running as
> FastCGI, external to the web server.

It's not so safe - it's still the same user for every script, so if appX
can read it's configuration file (with database password), then appY
have access too (unless restricted by safe_mode or dozens of
open_basedir).
So one should run one FastCGI process for every system account to be
secure, or there must be some SUID on the way (that's why I have written
about suexec+PHP-f?CGI).

> FastCGI application (including PHP interpreter) may be running on 
> a different account or even a different server then the web server
[...]

Nice. Doesn't it brake eAccelerator/other optimizers?

> IMHO the Apache's modules approach (mod_php, mod_python, mod_perl) is
> broken by design (interpreter built into the server process cannot be
> made multiuser and safe) and suexec and similar are only workarounds for
> CGI limitations.

Unfortunatelly, that's right...

> Maybe PLD could prepare some framework for running PHP applications via
> FastCGI under Apache?

apache-mod_fastcgi, apache-mod_fcgid or sth else? BTW description of
the latter says: 'and kick out the corrupt fastcgi server as soon as
possible'.

> But there still a problem similar to switching to
> lighttpd: some people just want or need mod_php/Apache and we won't help
> them by providing other, even better (in some ways) solution.

What other (incompatibile) changes need to be done?

-- 
Tom Pala <gotar at pld-linux.org>           http://vfmg.sourceforge.net/
                                         http://tccs.sourceforge.net/


More information about the pld-devel-en mailing list