This is freakin' ridiculous and exactly the type of we-know-better-than-you attitude that makes me consider stop supporting PHP all together.
If I want to use disable_functions on a local scale, for gods sake LET ME! I don't CARE about the performance issues as long as it allows me to secure my server.
The effect of not letting us do this is a server can not be secure in a multi-user environment with different user permissions, without applying admin nightmares such as separate apache instances or file permission controls that effectively ruins all of PHP's 3rd party add-ons.
Safe mode is not an option with todays requirements (phpBB etc) and as I understand it's even to be removed in PHP6.
Please do something about this to allow us server admins to get a good nights sleep.
Safe mode
Sommaire
Le "Safe Mode" est le mode de sécurité de PHP : une solution au problème de partage de PHP sur un serveur. Ce système pêche au niveau de l'architecture car il n'est pas correct de tenter de résoudre ce problème au niveau de PHP, mais les solutions alternatives basées sur le serveur web et l'OS ne sont pas réalistes. De nombreux intervenants, notamment les fournisseurs d'hébergement, utilisent le "Safe Mode".
Le "Safe Mode" est supprimé dans PHP 6.0.0.
Sécurité et Safe Mode
| Nom | Par défaut | Modifiable | Historique |
|---|---|---|---|
| safe_mode | "0" | PHP_INI_SYSTEM | Supprimé en PHP 6.0.0. |
| safe_mode_gid | "0" | PHP_INI_SYSTEM | Disponible depuis PHP 4.1.0. Supprimé en PHP 6.0.0. |
| safe_mode_include_dir | NULL | PHP_INI_SYSTEM | Disponible depuis PHP 4.1.0.Supprimé en PHP 6.0.0. |
| safe_mode_exec_dir | "" | PHP_INI_SYSTEM | Supprimé en PHP 6.0.0. |
| safe_mode_allowed_env_vars | "PHP_" | PHP_INI_SYSTEM | Supprimé en PHP 6.0.0. |
| safe_mode_protected_env_vars | "LD_LIBRARY_PATH" | PHP_INI_SYSTEM | Supprimé en PHP 6.0.0. |
| open_basedir | NULL | PHP_INI_ALL | PHP_INI_SYSTEM en PHP < 6. |
| disable_functions | "" | php.ini seulement | Disponible depuis PHP 4.0.1. |
| disable_classes | "" | php.ini seulement | Disponible depuis PHP 4.3.2. |
Voici un éclaircissement sur l'utilisation des directives de configuration.
- safe_mode booléen
-
Active ou non le mode de sécurité de PHP.
- safe_mode_gid booléen
-
Par défaut, le safe mode fait une comparaison des propriétaires, avant d'ouvrir un fichier. Si vous voulez alléger un peu ce niveau de sécurité, vous pouvez réaliser une comparaison de groupe, et activer cette directive. Si cette directive vaut FALSE (sa valeur par défaut), c'est une comparaison sur les UID, et, sinon, sur les GID.
- safe_mode_include_dir chaîne de caractères
-
Les vérifications basées sur le UID ou GID sont ignorées lorsque les fichiers inclus sont placés dans le dossier indiqué par cette directive, ainsi que ses sous-dossiers. Les dossiers peuvent être aussi dans l'include_path ou bien il faut inclure le chemin complet.
Depuis PHP 4.2.0, cette directive utilise le point virgule de la même façon que le fait include_path, pour permettre de configurer plusieurs dossiers. La restriction spécifiée est en fait un préfixe, plus qu'un nom de dossier. Cela signifie que "safe_mode_include_dir = /dir/incl" autorise aussi bien "/dir/include" que "/dir/incls", s'ils existent. Lorsque vous souhaitez restreindre l'accès à un dossier spécifique, il faut terminer cette directive avec un slash /. Par exemple "safe_mode_include_dir = /dir/incl/". Si la valeur de cette directive est vide, aucun fichier avec le UID/GID différent ne peut être inclus dans PHP 4.2.3 et dans les versions PHP 4.3.3 et plus récentes. Dans les versions antérieures, tous les fichiers pouvaient être inclus. - safe_mode_exec_dir chaîne de caractères
-
Si PHP est utilisé en safe mode, les fonctions comme system() et toutes celles qui permettent l'exécution en ligne de commande refuseront d'exécuter des programmes qui ne sont pas dans ce dossier. Vous devez utiliser / en tant que séparateur de dossier sous tous les environnements, y compris Windows.
- safe_mode_allowed_env_vars chaîne de caractères
-
Modifier certaines variables d'environnement est un trou de sécurité potentiel. Cette directive contient une liste de noms de variables d'environnement séparées par des virgules, ou de préfixes. En Safe mode, l'utilisateur ne pourra modifier que les variables d'environnement dont le nom commence par l'un des préfixes fourni ici. Par défaut, les utilisateurs ne peuvent modifier que les variables d'environnement qui commencent par PHP_ (e.g. PHP_FOO=BAR).
Note: Si cette directive est vide, PHP autorisera la modification de TOUTES les variables d'environnement.
- safe_mode_protected_env_vars chaîne de caractères
-
Cette directive contient une liste de variables d'environnement que le programmeur ne pourra pas modifier en utilisant la fonction putenv(). Ces variables seront protégées, même si la directive safe_mode_allowed_env_vars autorise leur modification.
- open_basedir chaîne de caractères
-
Limite les fichiers accessibles par PHP dans l'arborescence. Cette directive n'est pas affectée par le safe mode.
Lorsqu'un script tente d'ouvrir un fichier, avec les fonctions fopen() ou gzopen(), la situation du fichier est vérifiée. Si le fichier se situe hors du dossier spécifié dans cette directive, PHP refusera de l'ouvrir. Les liens symboliques sont résolus, ce qui fait que cette restriction ne peut être contournée par un lien symbolique. Si le fichier n'existe pas, le lien symbolique ne pourra pas être résolu et le nom de fichier sera comparé à open_basedir .
La valeur spéciale
.indique que le dossier dans lequel le script est stocké servira de dossier de base. Cela est cependant un peu dangereux car le dossier courant du script peut facilement être modifié avec la fonction chdir().Dans httpd.conf, open_basedir peut être désactivée (i.e. pour certains hôtes virtuels) de la même manière que toute autre directive de configuration avec la syntaxe "php_admin_value open_basedir none".
Sous Windows, séparez les dossiers par des points virgules. Sur les autres systèmes, séparez les dossiers avec des deux-points. Lorsque PHP est utilisé comme module Apache, les chemins de la directive open_basedir des dossiers parents sont automatiques transmis.
La restriction spécifiée par open_basedir est en fait un préfixe et non un dossier. Cela signifie que "open_basedir = /dir/incl" donne accès au dossier "/dir/include" et aussi au dossier "/dir/incls" s'il existe. Lorsque vous souhaitez restreindre l'accès à un dossier spécifique, ajoutez un slash final. Par exemple : open_basedir = /dir/incl/.
La valeur par défaut permet l'ouverture de tous les fichiers.
- disable_functions chaîne de caractères
- Cette directive vous permet de désactiver certaines fonctions pour des raisons de sécurité. Elle prend une liste de nom de fonctions, séparés par des virgules. disable_functions n'est pas affectée par le Safe Mode. Cette directive doit être configurée dans le fichier php.ini. Par exemple, vous ne pourrez pas la configurer dans le fichier httpd.conf.
- disable_classes chaîne de caractères
-
Cette directive vous permet de désactiver certaines classes
pour des raisons de sécurité. Elle
prend une liste de nom de fonctions, séparées par des
virgules. disable_functions
n'est pas
affectée par le Safe Mode.
Cette directive doit être configurée dans le fichier php.ini. Par exemple,
vous ne pourrez pas la configurer dans le fichier
httpd.conf.
Note: Disponibilité Cette directive est disponible depuis PHP 4.3.2
Voir aussi register_globals, display_errors et log_errors.
Lorsque Safe Mode est actif, PHP vérifie que le propriétaire du script courant est le même que le propriétaire des fichiers ou dossiers qui seront manipulés par ce script. Par exemple, dans la situation suivante :
-rw-rw-r-- 1 rasmus rasmus 33 Jul 1 19:20 script.php -rw-r--r-- 1 root root 1116 May 26 18:01 /etc/passwd
<?php
readfile('/etc/passwd');
?>
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/script.php on line 2
Cependant, il arrive que la vérification faite avec le nom du propriétaire du fichier soit trop restrictive, et qu'une vérification sur le nom du groupe soit suffisante. C'est une autre fonctionnalité supportée par la directive safe_mode_gid. En lui donnant la valeur de On, les vérifications seront faites sur le GID, alors qu'en lui laissant sa valeur par défaut de Off, les vérifications seront faites sur le UID.
Si au lieu d'utiliser le Safe Mode, vous utilisez la directive open_basedir, alors les manipulations seront limitées aux fichiers situés dans les dossiers spécifiés. Par exemple (Apache httpd.conf) :
<Directory /docroot> php_admin_value open_basedir /docroot </Directory>
Warning: open_basedir restriction in effect. File is in wrong directory in /docroot/script.php on line 2
Vous pouvez également désactiver les fonctions particulières. Notez que la directive disable_functions ne peut être utilisée en dehors du fichier php.ini, ce qui signifie que vous ne pouvez pas désactiver des fonctions par virtualhost ou par dossiers, dans votre fichier httpd.conf. Si nous ajoutons ceci à notre fichier php.ini :
disable_functions = readfile,system
Warning: readfile() has been disabled for security reasons in /docroot/script.php on line 2
Ces restrictions de PHP sont bien sûr invalides en exécution binaire.
Safe mode
07-May-2008 05:23
30-Jan-2008 05:42
Does anybody know how to allow ImageMagick read images in safe mode enabled.
I tried to change file/directory permissions, owners but it doesn't help.
Each time when I'm trying in PHP do "$im = new Imagick($imageFile);"
I have :
"
Uncaught exception 'ImagickException' with message 'Safe mode restricts user to read image: galeria/200108/DSC_8038.JPG'
"
23-Jan-2008 07:29
The location of the php.ini file is documented here:
http://www.php.net/manual/en/configuration.php
I agree that a hyperlink somewhere on the page would not be out of place.
16-Jan-2008 10:50
It would be nice if the documentation actually specified where the php.ini file is located.
Each IIS server in Windows runs as a User so it does have a UID file ACLs can be applied via a Group (GID) or User. The trick is to configure each website to run as a distinct user instead of the default of System.
01-Nov-2005 08:07
On the note of php security
have a look at: http://www.suphp.org/Home.html
suPHP is a tool for executing PHP scripts with the permissions of their owners. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp) that is called by the Apache module to change the uid of the process executing the PHP interpreter.
08-Aug-2005 01:25
I use mkdir just fine. You just have to make sure you set sticky bits on the directory you are creating the files in. Look at "man chmod" clipping:
4000 (the setuid bit). Executable files with this bit set will run with effective uid set to the uid of the file owner. Directories with this bit set will force all files and sub-directories created in them to be owned by the directory owner and not by the uid of the creating process, if the underlying file system supports this feature: see chmod(2) and the suiddir option to mount(8).
18-Jul-2005 10:19
It is possible to patch PHP/4 so it checks if just any directory in path is owned by proper user, e.g.
/home/mordae/www/dir/file
(where /home/mordae/www is mine and dir and file Apache's) will be readable if proper permissions set.
Read more at http://titov.net/safemodepatch/
18-Jul-2005 04:18
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.
To separate distinct open_basedir use : instead of on , or ; on unix machines.
29-Apr-2005 06:14
[In reply to jedi at tstonramp dot com]
Safe mode is used "since the alternatives at the web server and OS levels aren't very realistic". Manual says about UNIX OS level and UNIX web-servers by design (Apache). It's not realistic for unix-like server, but for NT (IIS) each virtual host can run from different user account, so there is no need in Safe Mode restrictions at all, if proper NTFS rights are set.
23-Sep-2004 08:58
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.
31-Aug-2004 11:52
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
}
?>
18-Mar-2004 03:03
on windows if multiple directories are wanted for safe_mode_exec_dir and open_basedir be sure to separate the paths with a semi colon and double quote the whole path string. For example:
safe_mode = On
safe_mode_exec_dir = "F:\WWW\HTML;F:\batfiles\batch"
open_basedir = "F:\WWW\HTML;F:\batfiles\batch"
26-Feb-2004 05:32
users executing shell scripts by filename.php, and I take the server in safe mode but some things are not working on web server, and disabled functions by php.ini but the simple commands in Unix are executing how disable to execute shell scripts via *.php file.
example
<?php
echo `ls -l /etc/`; echo `more /etc/passwd`;
?>
13-Nov-2003 01:38
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.
08-Mar-2003 10:44
readfile() seems not always to take care of the safe_mode setting.
When the file you want to read with readfile() resides in the same directory as the script itself, it doesn`t matter who the owner of the file is, readfile() will work.
27-Jan-2003 01:14
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.
17-Jan-2003 03:25
For people using linux there is a very nice solution to the shared server problem. It's called vserver/ctx. Here is the URL: http://www.solucorp.qc.ca/miscprj/s_context.hc
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.
disk_free_space($directory) is also restricted by the safe_mode ! It can also be completely forbidden as this would allow a script to test the available space in order to fill it with a giant file, preventing other scripts to use that space (notably in "/tmp").
disk_free_space() is then informational, and this does not prevent system quotas to limit the size of your files to a value lower than the available free space!
Most web server admins that propose PHP hosting, will implement quotas for your hosting account, but also on any shared resources such as temporary folders.
19-Jul-2002 04:33
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.
28-Apr-2002 11:42
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.
25-Jan-2002 08:45
Just to note, I created patch which allows VirtualHost to set User under which all (PHP too) runs. It is more secure than safe_mode. See luxik.cdi.cz/~devik/apache/ if you are interested
08-Sep-2001 10:17
Many filesystem-related functions are not appropriately restricted when Safe Mode is activated on an NT server it seems. I would assume that this is due to the filesystem not making use of UID.
In all of my scripts, no matter WHO owns the script (file Ownership-wise) or WHO owns the directory/file in question; both UIDs display
(getmyuid() and fileowner()) as UID = 0
This has the rather nasty side effect of Safe Mode allowing multiple filesystem operations because it believes the script owner and file/dir owner are one and the same.
While this can be worked around by the judicious application of proper filesystem privileges, it's still a "dud" that many of Safe Mode's securities are simply not there with an NT implementation.
