Something that I wrote recently that I thought may be of general interest for system administrators running PHP:
The web server runs on port 80, with the priviledges of the username "apache". On most webhosts that support PHP, this web server executes the PHP scripts. The PHP scripts would thus all run under the same username. Problem #1 is that a single web server generally services multiple websites. Under the common setup, all of their PHP scripts will run under the common "apache" username. This is a security flaw, because a programmer for a website would be able to read the PHP scripts of any other website, and probably also gain access to any databases or files that those scripts make use of. Most webhosts probably get away with this since one can only exploit this if they have an account on the server, can only attack other websites on the server, and most people aren't skilled/devious enough to do this. Problem #2 is that the use of PHP makes each Apache process consume more memory. The process consumes more memory even when it is serving static (non-PHP) files such as a JPG. It would be more efficient to have a pool of small processes serving static files, and some larger processes serving the PHP scripts. So on my server, the main web server on port 80 does not run PHP. Rather, the client has a private PHP-enabled Apache that listens on localhost port 8024. This private Apache runs under the priviledges of the client's UNIX account, and only serves pages from the client's domain. Whenever the main Apache receives a request that requires PHP to service(*), it will proxy the request to the PHP-enabled Apache. This solves problems #1 and #2 above. However, (*) is a bit problematic. Consider the following URLs: (a) http://www.domain.org/page.php (b) http://www.domain.org/page.html (c) http://www.domain.org/image.jpg (d) http://www.domain.org/ (a) should obviously be proxied, since it ends in .php and thus must be a PHP script. (b) and (c) have obvious static file extensions, so should not be proxied. But what about (d)? It could be either index.php or index.html, but this can't be determined just from pattern matching on the URL. I came up with a recipe in httpd.conf to account for case (d): In the case of a request to a directory, it will proxy if and only if index.php exists. RewriteEngine On # Proxy any request to *.php RewriteRule (.*)\.php$ http://127.0.0.1:8024$1.php [l,p] # Proxy any request to a directory if index.php exists RewriteCond %{REQUEST_URI} /$ RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME}index.php -f RewriteRule (.*) http://127.0.0.1:8024$1 [l,p] where http://127.0.0.1:8024 is the address to the backend PHP. %{DOCUMENT_ROOT} could be replaced with another directory path, if the PHP scripts are kept in a separate directory tree. Note that the RewriteCond -f means that the "apache" user will need to be able to list the files in the directory (but does not need read access to the files themselves). If more security is needed, the PHP files could be kept in a separate tree (configured as the DocumentRoot on the private Apache), and: RewriteCond %{DOCUMENT_ROOT}%{REQUEST_FILENAME}index.php -f could be replaced with a directive that determines whether the frontend Apache can handle the indexing for the directory (e.g. if index.html exists, or index.shtml, etc.), and not proxy if that is the case, and proxy otherwise. -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
