When PHP safe_mode is on
When safe_mode is on, PHP checks to see if the owner of the current script matches the owner of the file to be operated on by a file function or its directory. For example:
-rw-rw-r– 1 buddies buddies 43 Nov 1 19:20 passwd.php
-rw-r–r– 1 root root 1116 Nov 26 18:01 /etc/passwd
Running passwd.php: results in this error when safe mode is enabled:
Warning: SAFE MODE Restriction in effect. The script whose uid is 500 is not
allowed to access /etc/passwd owned by uid 0 in /docroot/passwd.php on line 2
However, there may be environments where a strict UID check is not appropriate and a relaxed GID check is sufficient. This is supported by means of the safe_mode_gid switch. Setting it to On performs the relaxed GID checking, setting it to Off (the default) performs UID checking.
If instead of safe_mode, you set an open_basedir directory then all file operations will be limited to files under the specified directory. For example (Apache httpd.conf example):
php_admin_value open_basedir /docroot
If you run the same script.php with this open_basedir setting then this is the result:
Warning: open_basedir restriction in effect. File is in wrong directory in /docroot/passwd.php on line 2
Protect Server Files by Default
One aspect of Apache which is occasionally misunderstood is the feature of default access. That is, unless you take steps to change it, if the server can find its way to a file through normal URL mapping rules, it can serve it to clients.
For instance, consider the following example:
1. # cd /; ln -s / public_html
2. Accessing http://localhost/~root/
This would allow clients to walk through the entire filesystem. To work around this, add the following block to your server’s configuration:
Order Deny,Allow
Deny from all
Protecting System Settings in Apache
To run a really tight ship, you’ll want to stop users from setting up .htaccess files which can override security features you’ve configured. Here’s one way to do it.
In the server configuration.
This prevents the use of .htaccess files in all directories apart from those specifically enabled.
What is suEXEC?
The suEXEC feature — introduced in Apache 1.2 — provides Apache users the ability to run CGI and SSI programs under user IDs different from the user ID of the calling web-server. Normally, when a CGI or SSI program executes, it runs as the same user who is running the web server.
Presently, suEXEC does not allow ‘root’ to execute CGI/SSI programs.
Used properly, this feature can reduce considerably the security risks involved with allowing users to develop and run private CGI or SSI programs. However, if suEXEC is improperly configured, it can cause any number of problems and possibly create new holes in your computer’s security. If you aren’t familiar with managing setuid root programs and the security issues they present, we highly recommend that you not consider using suEXEC.
Enabling & Disabling suEXEC
Upon startup of Apache, it looks for the file “suexec” in the “sbin” directory (default is “/usr/local/apache/sbin/suexec”). If Apache finds a properly configured suEXEC wrapper, it will print the following message to the error log:
[notice] suEXEC mechanism enabled (wrapper: /path/to/suexec)
If you don’t see this message at server startup, the server is most likely not finding the wrapper program where it expects it, or the executable is not installed setuid root.
If you want to enable the suEXEC mechanism for the first time and an Apache server is already running you must kill and restart Apache. Restarting it with a simple HUP or USR1 signal will not be enough.
If you want to disable suEXEC you should kill and restart Apache after you have removed the “suexec” file.
