Bug #14076 Updated: fopen() and touch() fail to create file under safe mode

From: 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

« previous php.bugs (#3937) next »