ID: 38670
Comment by: noc at smartterra dot de
Reported By: serokka at hrn dot ru
Status: Open
Bug Type: Apache2 related
Operating System: FreeBSD 4.10
PHP Version: 4.4.4
New Comment:
Update on my first submission on this bug:
I can reproduce it now on FreeBSD 6.2, Apache 2.0.59 and PHP4.4.7. No
.htaccess oder any other defined .html-Handler. Loading test.HTML
produces this error:
[Sat Jun 16 15:01:17 2007] [error] [client <myclientip>] PHP Warning:
Unknown(): SAFE MODE Restriction in effect. The script whose uid/gid is
1002/1002 is not allowed to access /usr/local/www/test owned by uid/gid
80/80 in Unknown on line 0
Previous Comments:
------------------------------------------------------------------------
[2007-04-24 23:02:50] gbjbaanb at users dot sourceforge dot net
I have Apache 2.0.59 with php 4.4.6 just installed and my sites, that
worked fine with php_admin_value open_basedir /home/xxx/:/tmp/:xxx
inside the vhost configuration now fail.
This is on CentOS 4.4, x86_64.
Quite serious? PHP has a reputation for insecure code, this is not
good.
------------------------------------------------------------------------
[2007-04-03 16:10:16] marcel dot prisi at virtua dot ch
I got the exact same problem on a FreeBSD-5.5 / Apache-2.0.59 /
php-4.4.6 (all from ports)
Adding a trailing slash to session.save_path didn't help, I had to
comment it from the virtualhost config in order to have the error go
away.
Quite serious I think ...
------------------------------------------------------------------------
[2007-03-14 13:02:05] david dot guenault at gmail dot com
update my precedent post :
if you simply add a trailing slash to session.save_path this will
discard the problem.
here is why :
in safe_mode.c in the function php_checkuid_ex
when mode argument is CHECKUID_ALLOW_ONLY_DIR
at line 119
s = strrchr(filename, DEFAULT_SLASH);
returns a pointer to the last occurrence of the character / in the
string filename. if your path is like this /data1sys/phpsession the
pointer is on the second slash not at the end of the path. The uid/gid
check is made on the parent folder (/data1sys) not the real folder
(/data1sys/phpsession). So when /data1sys is owned by a user that is
different from the user running apache, the test fail.
------------------------------------------------------------------------
[2007-03-14 10:14:18] david dot guenault at gmail dot com
first of all this is my environment
>SLES 10
>Apache 2.0.59
>Php 4.4.6
I use virtual host to configure my different web sites like this
<VirtualHost *:80>
DocumentRoot /data1user/apache/domain.tld
ServerName www.domain.tld
ErrorLog /data1sys/journaux/apache/domain/error_log
CustomLog /data1sys/journaux/apache/domain/access_log combined
# specific php configuration for this virtual host
php_admin_value doc_root /data1user/apache/domain.tld
php_admin_value session.save_path /data1sys/phpsession_domain.tld
php_admin_value file_uploads on
php_admin_value upload_tmp_dir /data1sys/phpupload_domain.tld
php_admin_value error_log
/data1sys/journaux/apache/testphp/php_domain.tld.log
</VirtualHost>
I've noticied one interesting thing.
before the error occure i check session.save_path => ok this is the
right directory.
When the error occure session.save_path back to the default value (aka
/tmp).
apache is running as user usrhttpd and group grphttpd. The top level
directory for storing session is /data1sys and is owned by user root and
group root. The directory used to store sessions is
phpsession_domain.tld under /data1sys and is owned by
usrhttpd:grphttpd.
If i change /datasys group to grphttpd the error disapear.
If i remove the directive php_admin_value session.save_path
/data1sys/phpsession_domain.tld. from my vhost then all is going right.
hope this help.
------------------------------------------------------------------------
[2007-03-09 07:18:31] mspado at hotmail dot com
Forgot to say:
A common thread to issues with this bug has been the use of
'php_admin_value upload_tmp_dir /xxx/xxx/xxx/tmp'
M.
------------------------------------------------------------------------
The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at
http://bugs.php.net/38670
--
Edit this bug report at http://bugs.php.net/?id=38670&edit=1
