某位哥哥因为看着wordpress3.3的升级提示激动了，一不小心就将它升级了，升级后一切正常，只是之前可用的附件上传功能现在不能用了，显示报错如下:
Warning: touch() [function.touch]: SAFE MODE Restriction in effect. The script whose uid is 10041 is not allowed to access /tmp owned by uid 0 in ...... |
各种纠结……
依据提示我们知道是由于PHP开启了安全模式的原因，最简单的办法：修改php.ini文件，将safe_mode设置为off，将安全模式关闭。
只是这是生产环境，关闭安全模式不太靠谱。只能换方案。
依据刚才的错误提示，我们知道是安全模式在检查执行程序的文件的UID与需要写入的文件夹的UID不一样，这是因为在PHP的安全模式中，对于部分函数是需要检查被操作的文件或目录是否与被执行的脚本有相同的 UID（所有者），很不幸，touch就是这样的函数之一。当然，有这个规则就应该有跳过这个规则的办法，在php.ini文件中，我们可以设置safe_mode_include_dir参数，多个路径以冒号隔开(Windows是分号)，在此参数内设置的目录及其子目录都将会越过 UID/GID 检查。
除此之外，安全模式相关的还有一个open_basedir设置项，PHP 所能打开的文件限制在open_basedir指定的目录树，包括文件本身。本指令不受安全模式打开或者关闭的影响。
safe_mode_include_dir和open_basedir指定的限制实际上是一个前缀，而非一个目录名。这也就是说“safe_mode_include_dir = /tmp”将允许访问“/tmp和“/template”(如果它们存在的话)，。如果希望将访问控制在一个指定的目录，那么请在结尾加上一个斜线，例如：“safe_mode_include_dir = /tmp”。
这两个与本次安全问题相关的内容都添加了/tmp和当前操作的目录，发现依旧报错。
追根溯源，从源码中开始吧，如果对于PHP源码不太熟悉，那么我们可以从本次事件的关键点safe_mode_include_dir开始。
在PHP源码中搜索safe_mode_include_dir，除了与此配置项相关的初始化操作，我们可以找到验证此项的函数php_check_safe_mode_include_dir。现在，我们可以用GDB debug的方法查看，给php_check_safe_mode_include_dir函数增加断点，运行一个你认为一定会经过此参数检查的PHP函数调用，如fopen等。运行，发现会在断点处停下，如果我们运行一个只包含了touch函数的代码，会发现程序会执行完，即touch函数根本就没有调用php_check_safe_mode_include_dir函数，即在安全模式下，根本无法跳过UID的检测。
或者我们直接查看touch函数的PHP源码实现，其代码在/ext/standard/filestat.c文件649行。在其代码中我们可以清楚的看到其实现过程在处理了相关参数后，就直接判断完全模式和检测UID了，如下代码:
PHP_FUNCTION(touch) { ... /* Safe-mode */ if (PG(safe_mode) && (!php_checkuid(filename, NULL, CHECKUID_CHECK_FILE_AND_DIR))) { RETURN_FALSE; } /* Check the basedir */ if (php_check_open_basedir(filename TSRMLS_CC)) { RETURN_FALSE; } ... } |
找到了问题的根源，也许是PHP的BUG，也许是其它考量，待确认。
那么这个问题怎么解决呢？
比较wordpress3.3和wordpress3.2的代码，我们发现wordpress在处理附件上传时最终都会调用wp_handle_upload函数（/wp-admin/include/file.c）。在此函数中wordpress3.3版本多了一句：
$tmp_file = wp_tempnam($filename); |
在wp_tempnam函数中，最终会通过touch生成临时文件，从前面我们可以知道我们暂时无法解决在此环境下的touch函数的问题，那么我们只能适应这个函数，也就是说我们需要将新创建的临时文件的目录UID和执行的PHP文件的UID设置为一样，那么这个临时文件的目录是否可以改变？我们查看wp_tempnam函数，发现其最先取的临时目录的地址为常量WP_TEMP_DIR的值，此值默认是没有设置的，如果这个值没有才会取其它值。此时，解决方案就浮出水面了：在wp-config.php文件中设置常量WP_TEMP_DIR的值为网站目录下某个UID和PHP脚本一样UID的目录即可。
附gdb bt显示的内容
#0 php_check_safe_mode_include_dir (path=0x86f4fcc "/tmp/aaa43243.tmp") at /home/martin/project/c/phpsrc/main/fopen_wrappers.c:319 #1 0x0829d97b in php_plain_files_stream_opener (wrapper=0x85eb624, path=0x86f4fcc "/tmp/aaa43243.tmp", mode=0x86f6b38 "a", options=4, opened_path=0x0, context=0x86f5560) at /home/martin/project/c/phpsrc/main/streams/plain_wrapper.c:991 #2 0x0829842d in _php_stream_open_wrapper_ex ( path=0x86f4fcc "/tmp/aaa43243.tmp", mode=0x86f6b38 "a", options=12, opened_path=0x0, context=0x86f5560) at /home/martin/project/c/phpsrc/main/streams/streams.c:1867 #3 0x08229b73 in php_if_fopen (ht=2, return_value=0x86f5544, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /home/martin/project/c/phpsrc/ext/standard/file.c:909 #4 0x0817b088 in phar_fopen (ht=2, return_value=0x86f5544, return_value_ptr=0x0, this_ptr=0x0, return_value_used=1) at /home/martin/project/c/phpsrc/ext/phar/func_interceptors.c:418 #5 0x0831b9a1 in zend_do_fcall_common_helper_SPEC (execute_data=0x8727eb8) at /home/martin/project/c/phpsrc/Zend/zend_vm_execute.h:313 #6 0x082f4bc6 in execute (op_array=0x86f545c) at /home/martin/project/c/phpsrc/Zend/zend_vm_execute.h:104 #7 0x082d2256 in zend_execute_scripts (type=8, retval=0x0, file_count=3) ---Type <return> to continue, or q <return> to quit--- at /home/martin/project/c/phpsrc/Zend/zend.c:1194 #8 0x08281b70 in php_execute_script (primary_file=0xbffff2a0) at /home/martin/project/c/phpsrc/main/main.c:2225 #9 0x08351b97 in main (argc=4, argv=0xbffff414) at /home/martin/project/c/phpsrc/sapi/cli/php_cli.c:1190 |
我说我怎么没遇到这种问题：一是俺很少用各种插件，二是…俺是个777党，php-fpm一直跑在root中。。。汗～
各种膜拜，居然是root