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.