[thelist] PHP Perl Apache security

[SBeam]

Keith - interesting post. One thing that comes to mind, is that the insecurity 
of writing to files is just one of the major drawbacks of virtual hosting. 
Most developers who have the ability to write to static files using Perl/PHP 
should be aware of this. As a hosting provider, you might do well to make 
that clear, and use the opportunity to upsell them to dedicated (most hosts 
do). otherwise...

On Sunday 20 July 2003 01:44 am, Keith wrote:
> PHP as CGI/suExec scenario:
> Instead of running PHP as an Apache module, run it as a CGI. With suExec,
> PHP run as a CGI will inherit the same security that Perl has - PHP can
> write to a file owned by the same user with only rw - - permissions. Since
> world permissions do not need to be set for either PHP or Perl to write to
> the file, 600 permission will work making the file unreadable/unwritable.
> Problem: 1) running PHP as CGI is very inefficient/expensive. 

true - but not prohibitively so. I use a certain undisclosed Vhost that uses 
this strategy, and while I have no idea what the hardware etc. is, 
performance is very good. and again, if you want great performance, you 
should not be on a vhost anyway. 

> 2) running as
> a CGI requires that a PHP shebang (#!/usr/bin/php) be added to all PHP
> files - not a problem if you're just starting out but imagine the hassles
> if you have 15,000 hosting clients on more than 50 servers that will
> suddenly discover their PHP files no longer work.

not necessarily. There is a way to avoid this and I _think_ it involves the 
Action directive :P (sorry). Again, my undisclosed host does it and I have 
done it but can't remember how exactly... I think you do
    AddType  application/x-httpd-php .php
    Action application/x-httpd-php /cgi-bin/php
inside the <VirtualHost> section.

the drawback with this method: any php_value directives set in .htaccess files 
(these override settings in php.ini) will not be recognized. Pretty rare 
anyway and...

the bonus advantage with this method: users can have their own php.ini files - 
and their own version of php! Just complile php as CGI, point the 
configuration directive for the php.ini location to their working dir, put 
the binary in their cgi-bin... (well, ok, times 15,000...)

So, I vote for this method. In fact, as a customer I prefer it too, as long as 
the performance is ok. No more security problems, all files are owned by user 
- if a customer needs version 4.2.x of php, you can do that - if they want to 
mess with the php.ini settings, they can do that - and if they want to run 
php from the command line, they can do that... seems to make perfect sense 
for a vhost environment.