PHP's safe_mode: notes on the web.

The PHP safe mode is an attempt to solve the shared-server security problem.
It is architecturally incorrect to try to solve this problem at the PHP level, but since the alternatives at the web server and OS levels aren't so easy, many people, especially ISP's, use safe mode for now.

The problem is that Safe Mode is deprecated in PHP 5.3.0 and is removed in PHP 6.0.0.

How Turning off safe_mode on a Dedicated-Virtual Server?

Once logged in (root user) edit /etc/php.ini with a text editor. Change the following line:

safe_mode = On   
safe_mode = Off

Then restart httpd server:

/etc/init.d/httpd stop
/etc/init.d/httpd start 

An article about why avoiding safe_mode:
http://ilia.ws/archives/18_PHPs_safe_mode_or_how_not_to_implement_security.html
safe_mode can be set in php.ini or httpd.conf. It will not work with .htaccess.

Note that safe mode is largely useless. Most ISPs that offer Perl also offer other scripting languages (mostly Perl), and these other languages don't have the equivalent of PHP.
In other words, if PHP's safe mode won't allow vandals into your web presence, they will simply use Perl.
Also, safe mode prevents scripts from creating and using directories (because they will be owned by the WWW server, not by the user who uploaded the PHP script). So it's not only useless, it's also a hindrance.
The only realistic option is to bugger the Apache folks until they run all scripts as the user who's responsible for a given virtualhost or directory.

Beware that when in safe mode, mkdir creates folders with apache's UID, though the files you create in them are of your script's UID (usually the same as your FTP uid).
What this means is that if you create a folder, you won't be able to remove it, nor to remove any of the files you've created in it (because those operations require the UID to be the same).
Ideally mkdir should create the folder with the script's UID, but this has already been discussed and will not be fixed in the near future. In the meantime, I would advice NOT to user mkdir in safe mode, as you may end up with folders you can't remove/use.

Use open_basedir :
http://php.net/manual/en/ini.sect.safe-mode.php

Check and fix this bug
http://bugs.php.net/bug.php?id=42836

Sometimes you're stuck on a system you don't run and you can't control the setting of safe mode. If your script needs to run on different hosts (some with safe mode, some without it), you can code around it with something like:

<?php
// Check for safe mode
if( ini_get('safe_mode') ){
    // Do it the safe mode way
}else{
    // Do it the regular way
}
?>

Beware: Safe mode will not permit you to create new files in directories which have different owner than the owner of the script. This typically applies to /tmp, so contrary to Unix intuition, you will not be able to create new files there (even if the /tmp rights are set correctly).
If you need to write into files in /tmp (for example to put logfiles of your PHP application there) create them first on the command line by doing a touch /tmp/whatever.log as the same user who owns the PHP script. Then, provided the rest is configured correctly, the PHP script will be able to write into that file.

zebz: The user would not be able to create a directory outside the namespace where he/she would be able to modify its contents. One can't create a directory that becomes apache-owned unless one owns the parent directory.

Another security risk: since files created by apache are owned by apache, a user could call the fputs function and output PHP code to a newly-created file with a .php extension, thus creating an apache-owned PHP script on the server. Executing that apache-owned script would allow the script to work with files in the apache user's namespace, such as logs. A solution would be to force PHP-created files to be owned by the same owner/group as the script that created them. Using open_basedir would be a likely workaround to prevent ascension into uncontrolled areas.

Some paranoid web managers also restrict the set_user_abort() function.
This constitutes a security issue for hosted web sites, because the hosted script cannot guarantee safe atomic operations on files in a reasonnable time (the time limit may still be in effect):
If set_user_abort() is disabled by the web admin, a user can corrupt the files of a hosted web site by simply sending many requests to the PHP script, and aborting it fast. In some cases that can be easily reproduced after a dozen of attempts, the script will be interrupted in the middle of a file or database update!
The only way for the hosted web site to protect itself in this case is to use a sleep() with a random but not null short time before performing atomic operations.
Web admins should then definitely NOT disable the set_user_abort() function which is vital to ensure atomic operations on hosted critical files or databases.
Instead they should only disable the set_time_limit() function, and set a constant but reasonnable time for any script to complete their atomic operations.

open_basedir only restricts file operations to files and directories under a specified directory, but you can still user system ("vi /home/somedir/somefile"), so safe_mode still has a place here as it is much more restrictive then open_basedir.
Also, to reply to someone who said that 'above' and 'below' was a matter of perspective, sure it is. Of course, a file is not under another one, etc, it just pointed by some inode. But in the common language we consider the root (/) to be above everything else, and /home is below root, and /home/myfile is below /home. There is no written standard, but most people (those I know anyway) agree on that syntax.

All the filesystem-related functions (unlink, fopen, unlink, etc) seems to be restricted the same way in safe mode, at least on PHP 4.2. If the file UID is different *but* the directory (where the file is located) UID is the same, it will work.
So creating a directory in safe mode is usually a bad idea since the UID will be different from the script (it will be the apache UID) so it won't be possible to do anything with the files created on this directory.