Bug #14076 Updated: fopen() and touch() fail to create file under safe mode
| From: | phpbugs at noerenberg dot de | Date: | Wed, 03 Apr 2002 16:56:31 +0000 |
| Subject: | Bug #14076 Updated: fopen() and touch() fail to create file under safe mode | ||
| References: | 1 | Groups: | php.bugs |
| Request: | Send a blank email to php-bugs+get-3937@lists.php.net to get a copy of this message | ||
ID: 14076
Updated by: phpbugs@noerenberg.de
Reported By: a.genkin@utoronto.ca
Status: Open
Bug Type: *Directory/Filesystem functions
Operating System: Linux
PHP Version: 4.0.6
New Comment:
This bug still exists in PHP 4.1.2.
A similiar problem also affects safe_mode_include_dir (path-statements
containing symlinks do not work: "The script whose uid is 1234 is not
allowed to access /my/safe_mode_include_path/with/symlink/mail.php
owned by uid 0").
Could someone *please* fix this ?
Hajo
Previous Comments:
------------------------------------------------------------------------
[2002-01-17 14:59:12] phpbugs@noerenberg.de
I've verified that this problem still exists in PHP 4.1.1.
Hajo Noerenberg
------------------------------------------------------------------------
[2002-01-16 13:42:52] phpbugs@noerenberg.de
As a workaround you can use relative paths in all of
your fopen()-calls: fopen("./test.html") always works
(I think php prepends the *expanded path* then -- see
the last paragraph in my previous comment).
Hajo
------------------------------------------------------------------------
[2002-01-16 13:21:11] phpbugs@noerenberg.de
This problem has nothing to do with wrong file/directory modes. I'm
quite sure that it is a bug in the PHP-realpath-code.
Please consider the following setup layout:
/var/www/ = symlink to /mnt/sda1/www
/var/www/domain.com = apache document_root = php open_basedir
/var/www/domain.com/test.html = test file for fopen()
I've added some debug code to fopen_wrappers.c :
php_error(E_NOTICE, "check_specific_open_basedir ( comparing resolved
name %s to resolved_basedir %s )", resolved_name, resolved_basedir);
if (strncmp(resolved_basedir, resolved_name, strlen(resolved_basedir))
== 0) {
Trying to fopen("/var/www/domain.com/test.html") results
in two cases:
1. /var/www/domain.com/test.html already exists
PHP Warning: check_specific_open_basedir ( comparing resolved name
/mnt/sda1/www/domain.com/test.html to resolved_basedir
/mnt/sda1/www/domain.com/test.html )
-> fopen() succeeds
2. /var/www/domain.com/test.html does *not* exist
PHP Warning: check_specific_open_basedir ( comparing resolved name
/var/www/domain.com/test.html to resolved_basedir
/mnt/sda1/www/domain.com/test.html )
-> fopen() fails with "open basedir restriction in effect"-error
As you can see in the debug output, PHP does not correctly
expand the file path if the file does not exists !
Trying to fopen("/mnt/sda1/www/domain.com/test.html") always
succeeds because PHP does not need to expand the filename anymore
(-> strncmp is always true ).
Hajo
(Linux 2.2 - PHP 4.0.6 - afaik the problem still exists in 4.1.X)
------------------------------------------------------------------------
[2001-11-19 13:50:10] a.genkin@utoronto.ca
Well, the fact that it can create a *new directory* in the same
directory, already means that the apache process has sufficient
permissions to also create a file in it. However, these are the
permissions:
webedit@penguin:/var/www/tmp/submit$ ls -lad ./
drwxrwx--- 18 webedit www 4096 Nov 15 19:13 ./
Apache runs as user
www', and the scripts are owned by user webedit'.
Note that the directory is owned by the same user as the script, and
writeable to Apache, so the requirements of safe mode are met.
Thank you for your response.
--
Arcady Genkin
------------------------------------------------------------------------
[2001-11-19 12:37:01] bate@php.net
Post please the
mod of your directory and tell me the
user and group of your apache. Maybe the apache dont have
rights to create a new file in your directory but he owns the newfile
and can remove/edit this file.
------------------------------------------------------------------------
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/14076
--
Edit this bug report at http://bugs.php.net/?id=14076&edit=1