Philip Mak wrote:
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.
check out php_admin_value open_basedir, should solve this. allows you
to specify what directory's a php script can read from.
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.
can't think of any other way to solve this problem than what you've done.
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
