[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