php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #14076 fopen() and touch() fail to create file under safe mode
Submitted: 2001-11-15 18:53 UTC Modified: 2002-08-18 03:37 UTC
Votes:9
Avg. Score:4.9 ± 0.3
Reproduced:7 of 8 (87.5%)
Same Version:3 (42.9%)
Same OS:4 (57.1%)
From: a dot genkin at utoronto dot ca Assigned:
Status: Closed Package: *Directory/Filesystem functions
PHP Version: 4.3.0-dev OS: Linux
Private report: No CVE-ID: None
 [2001-11-15 18:53 UTC] a dot genkin at utoronto dot ca
Under safe mode, fopen("filename", "w") fails to create a file if it doesn't exist, complaining about open_basedir restriction.  However, the filename refers to the file in the directory configured in the open_basedir.  Besides, if the same file is created manually, fopen() can open it for writing without  any problems.  The directory is writeable to the web server.

$dir = '/var/www/tmp/submit';

// Fails if the file doesn't exist.
// Succeeds if the file does exist
fopen( "$dir/file.txt", "w" ); // Fails if the file doesn't exist.
mkdir( "$dir/foo", 0700 ); // SUCCEEDS!!! Notice the same path.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2001-11-19 12:37 UTC] 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.

 [2001-11-19 13:50 UTC] a dot genkin at utoronto dot 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
 [2002-01-16 13:21 UTC] phpbugs at noerenberg dot 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)
 [2002-01-16 13:42 UTC] phpbugs at noerenberg dot 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-17 14:59 UTC] phpbugs at noerenberg dot de
I've verified that this problem still exists in PHP 4.1.1.

Hajo Noerenberg
 [2002-04-03 11:56 UTC] phpbugs at noerenberg dot de
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
 [2002-04-03 11:59 UTC] derick@php.net
This should be fixed. Please see www.php.net/~derick for the latest RC for 4.2.0m, and report back.

Derick
 [2002-04-03 15:38 UTC] phpbugs at noerenberg dot de
Unfortunately this bug is *not* fixed in 4.2.0rc1.

I can reproduce both problems (fopen fails if file does not exist / safe_mode_includedir does not work). If I use "real" path statements (e.g. /mnt/hda7/web/file.php instead of /var/web/file.php) everything works fine (please see my previous posts to #14076)

Let me know if I can help with more tests or debug output. It would be very nice to have this problem fixed in the next release.

Hajo
 [2002-04-16 07:33 UTC] byg at cf1 dot ru
I could not reproduce this issue.
Here's my layout for the virtual server (from httpd.conf):
DocumentRoot /path_to_site/html
Options FollowSymLinks

php_admin_value open_basedir path_to_sitephp_admin_value doc_root path_to_site
php_admin_value safe_mode_include_dir path_to_site
safe_mode=on in php.ini
PHP version: both 4.0.6 and 4.2.0RC2
create PHP-script at "path_to_site/html/scriptname"
create directory "path_to_site/html/test" writable by the apache user, then make symlink "path_to_site/html/test2" to that directory

<?
$fh=fopen("$DOCUMENT_ROOT/test2/1.txt", "w");
fwrite($fh, "test\n");
echo $fh,"\n";
fclose($fh);
mkdir("$DOCUMENT_ROOT/test2/xxx/",770);
?>


lynx http://sitename/scriptname gives "Resource id#1"

No errors found in php_error_log,
looked at path_to_site/html/test2/ and saw there both 1.txt contained "test" and xxx subdirectory.
 [2002-04-17 03:35 UTC] phpbugs at noerenberg dot de
byg@cf1.ru wrote:
>I could not reproduce this issue.
>Here's my layout for the virtual server (from httpd.conf)

The symlink has to be *within* path_to_site, e.g.:

/var/www/ = symlink to /mnt/sda1/www
/var/www/domain.com = apache document_root = php open_basedir

Please see my posting from 16 Jan 1:21pm for details ( http://bugs.php.net/bug.php?id=14076 ).

Hajo
 [2002-05-04 00:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2002-05-04 03:53 UTC] a dot genkin at utoronto dot ca
Erm... Hajo provided feedback.
 [2002-05-04 03:55 UTC] a dot genkin at utoronto dot ca
I don't seem to be able to change the status to Open...  How do I do it?!
 [2002-07-10 23:49 UTC] sniper@php.net
Please try this snapshot:

http://snaps.php.net/php4-latest.tar.gz
 [2002-07-30 12:40 UTC] phpbugs at noerenberg dot de
I can not check if this bug has been solved (php4-200207300900 does not install correctly and produces segfaulting apache childs). I'll check back next week and provide feedback asap.

Maybe someone can give me a hint where (CVS) to find the necessary code-changes and whether it is possible to back-port some to the current php-stable.

Hajo
 [2002-08-11 01:00 UTC] php-bugs at lists dot php dot net
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".
 [2002-08-12 04:07 UTC] mj@php.net
I'm able to reproduce this bug here.
 [2002-08-14 17:51 UTC] sniper@php.net
Thank you for taking the time to report a problem with PHP.
Unfortunately you are not using a current version of PHP -- 
the problem might already be fixed. Please download a new
PHP version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to "Open".
Again, thank you for your continued support of PHP.


 [2002-08-14 17:52 UTC] sniper@php.net
Oops..misread. Assuming this was reproduced with latest CVS HEAD.

 [2002-08-18 03:37 UTC] iliaa@php.net
This bug has been fixed in CVS.

In case this was a PHP problem, snapshots of the sources are packaged
every three hours; this change will be in the next snapshot. You can
grab the snapshot at http://snaps.php.net/.
 
In case this was a documentation problem, the fix will show up soon at
http://www.php.net/manual/.

In case this was a PHP.net website problem, the change will show
up on the PHP.net site and on the mirror sites in short time.
 
Thank you for the report, and for helping us make PHP better.


 
PHP Copyright © 2001-2021 The PHP Group
All rights reserved.
Last updated: Thu Oct 28 16:03:36 2021 UTC