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.
章 42. 安全模式
PHP 的安全模式是为了试图解决共享服务器（shared-server）安全问题而设立的。在结构上，试图在 PHP 层上解决这个问题是不合理的，但修改 web 服务器层和操作系统层显得非常不现实。因此许多人，特别是 ISP，目前使用安全模式。
保安措施和安全模式
表格 42-1. 保安措施和安全模式配置指令
| 名称 | 默认值 | 可修改范围 | 更新记录 |
|---|---|---|---|
| safe_mode | "0" | PHP_INI_SYSTEM | |
| safe_mode_gid | "0" | PHP_INI_SYSTEM | 自 PHP 4.1.0 起可用 |
| safe_mode_include_dir | NULL | PHP_INI_SYSTEM | 自 PHP 4.1.0 起可用 |
| safe_mode_exec_dir | "" | PHP_INI_SYSTEM | |
| safe_mode_allowed_env_vars | "PHP_" | PHP_INI_SYSTEM | |
| safe_mode_protected_env_vars | "LD_LIBRARY_PATH" | PHP_INI_SYSTEM | |
| open_basedir | NULL | PHP_INI_SYSTEM | |
| disable_functions | "" | 仅 php.ini | 自 PHP 4.0.1 起可用 |
| disable_classes | "" | 仅 php.ini | 自 PHP 4.3.2 起可用 |
以下是配置选项的简要解释。
- safe_mode boolean
是否启用 PHP 的安全模式。更多信息请阅读安全一章。
- safe_mode_gid boolean
默认情况下，安全模式在打开文件时会做 UID 比较检查。如果想将其放宽到 GID 比较，则打开 safe_mode_gid。是否在文件访问时使用 UID（FALSE）或者 GID（TRUE）来做检查。
- safe_mode_include_dir string
当从此目录及其子目录（目录必须在 include_path 中或者用完整路径来包含）包含文件时越过 UID/GID 检查。
从 PHP 4.2.0 开始，本指令可以接受和 include_path 指令类似的风格用冒号（Windows 中是分号）隔开的路径，而不只是一个目录。
指定的限制实际上是一个前缀，而非一个目录名。这也就是说“safe_mode_include_dir = /dir/incl”将允许访问“/dir/include”和“/dir/incls”，如果它们存在的话。如果希望将访问控制在一个指定的目录，那么请在结尾加上一个斜线，例如：“safe_mode_include_dir = /dir/incl/”。
如果本指令的值为空，在 PHP 4.2.3 中以及 PHP 4.3.3 起具有不同 UID/GID 的文件将不能被包含。在较早版本中，所有文件都能被包含。
- safe_mode_exec_dir string
如果 PHP 使用了安全模式，system() 和其它程序执行函数将拒绝启动不在此目录中的程序。必须使用 / 作为目录分隔符，包括 Windows 中。
- safe_mode_allowed_env_vars string
设置某些环境变量可能是潜在的安全缺口。本指令包含有一个逗号分隔的前缀列表。在安全模式下，用户只能改变那些名字具有在这里提供的前缀的环境变量。默认情况下，用户只能设置以 PHP_ 开头的环境变量（例如 PHP_FOO = BAR）。
注: 如果本指令为空，PHP 将使用户可以修改任何环境变量！
- safe_mode_protected_env_vars string
本指令包含有一个逗号分隔的环境变量的列表，最终用户不能用 putenv() 来改变这些环境变量。甚至在 safe_mode_allowed_env_vars 中设置了允许修改时也不能改变这些变量。
- open_basedir string
将 PHP 所能打开的文件限制在指定的目录树，包括文件本身。本指令不受安全模式打开或者关闭的影响。
当一个脚本试图用例如 fopen() 或者 gzopen() 打开一个文件时，该文件的位置将被检查。当文件在指定的目录树之外时 PHP 将拒绝打开它。所有的符号连接都会被解析，所以不可能通过符号连接来避开此限制。
特殊值 . 指明脚本的工作目录将被作为基准目录。但这有些危险，因为脚本的工作目录可以轻易被 chdir() 而改变。
在 httpd.conf 文件中中，open_basedir 可以像其它任何配置选项一样用“php_admin_value open_basedir none”的方法关闭（例如某些虚拟主机中）。
在 Windows 中，用分号分隔目录。在任何其它系统中用冒号分隔目录。作为 Apache 模块时，父目录中的 open_basedir 路径自动被继承。
用 open_basedir 指定的限制实际上是前缀，不是目录名。也就是说“open_basedir = /dir/incl”也会允许访问“/dir/include”和“/dir/incls”，如果它们存在的话。如果要将访问限制在仅为指定的目录，用斜线结束路径名。例如：“open_basedir = /dir/incl/”。
注: 支持多个目录是 3.0.7 加入的。
默认是允许打开所有文件。
- disable_functions string
本指令允许你基于安全原因禁止某些函数。接受逗号分隔的函数名列表作为参数。 disable_functions 不受安全模式的影响。
本指令只能设置在 php.ini 中。例如不能将其设置在 httpd.conf。
- disable_classes string
本指令可以使你出于安全的理由禁用某些类。用逗号分隔类名。disable_classes 不受安全模式的影响。
本指令只能设置在 php.ini 中。例如不能将其设置在 httpd.conf。
可用性说明: 本指令自 PHP 4.3.2 起可用。
参见 register_globals，display_errors 和 log_errors。
当 safe_mode 设置为 on，PHP 将通过文件函数或其目录检查当前脚本的拥有者是否和将被操作的文件的拥有者相匹配。例如：
-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 |
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 |
同时，或许会存在这样的环境，在该环境下，宽松的 GID 检查已经足够，但严格的 UID 检查反而是不适合的。可以用 safe_mode_gid 选项来控制这种检查。如果设置为 On 则进行宽松的 GID 检查；设置为 Off（默认值）则进行 UID 检查。
除了 safe_mode 以外，如果设置了 open_basedir 选项，则所有的文件操作将被限制在指定的目录下。例如：
<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 |
也可以单独地屏蔽某些函数。请注意 disable_functions 选项不能在 php.ini 文件外部使用，也就是说无法在 httpd.conf 文件的按不同虚拟主机或不同目录的方式来屏蔽函数。如果将如下内容加入到 php.ini 文件：
disable_functions readfile,system |
Warning: readfile() has been disabled for security reasons in /docroot/script.php on line 2 |
| 警告 |
当然，这些 PHP 限制不适用于可执行文件。 |
add a note
User Contributed Notes
15-Sep-2006 01:18
mailrinke at yahoo dot com
15-Feb-2006 06:20
15-Feb-2006 06:20
Note that safemode restricts setting the sticky bits, so this may not be an option
martin at example dot com
01-Nov-2005 08:07
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.
hunter+phpnet at spysatcentral dot net
08-Aug-2005 01:25
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).
mordae at mordae dot net
18-Jul-2005 10:19
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/
jo at durchholz dot org
18-Jul-2005 04:18
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.
04-May-2005 12:37
To separate distinct open_basedir use : instead of on , or ; on unix machines.
plyrvt at mail dot ru
29-Apr-2005 06:14
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.
bertrand dot gorge at epistema dot com
23-Sep-2004 08:58
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.
Russ
31-Aug-2004 11:52
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
}
?>
daniel dot gaddis at tlc dot state dot tx dot us
18-Mar-2004 03:03
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"
uuganbat at datacom dot mn
26-Feb-2004 05:32
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`;
?>
matthias at remove-this dot hrz dot uni-kassel dot de
13-Nov-2003 01:38
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.
info at phpcoding dot net
08-Mar-2003 10:44
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.
gtg782a at mail dot gatech dot edu
27-Jan-2003 01:14
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.
dizzy at roedu dot net
17-Jan-2003 03:25
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
10-Sep-2002 06:30
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.
10-Sep-2002 06:19
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.
tom at tom420 dot com
19-Jul-2002 04:33
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.
zebz at ihaveenoughspam_hotmail dot com
28-Apr-2002 11:42
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.
devik at cdi dot cz
25-Jan-2002 08:45
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
jedi at tstonramp dot com
08-Sep-2001 10:17
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.