php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #21885 move_uploaded_file error with open_basedir
Submitted: 2003-01-26 05:01 UTC Modified: 2005-01-31 23:30 UTC
Votes:5
Avg. Score:3.8 ± 1.5
Reproduced:4 of 5 (80.0%)
Same Version:4 (100.0%)
Same OS:1 (25.0%)
From: mak77 at anvi dot it Assigned: wez (profile)
Status: Closed Package: Safe Mode/open_basedir
PHP Version: 4.3.1-dev OS: any
Private report: No CVE-ID: None
 [2003-01-26 05:01 UTC] mak77 at anvi dot it
i've a script that worked well with 4.2.2, this scripts makes an upload

my ini is set to:

open basedir=. 

;;;;;;;;;;;;;;;;
; File Uploads ;
;;;;;;;;;;;;;;;;

; Whether to allow HTTP file uploads.
file_uploads = On

; Temporary directory for HTTP uploaded files (will use system default if not
; specified).
upload_tmp_dir ="c:\temp\php-uploads"

; Maximum allowed size for uploaded files.
upload_max_filesize = 6M


my script does simply:

move_uploaded_file($_FILES['new_file_file']['tmp_name'],
$this->path.$this->filename);
in my class...

it gives me:

Warning: move_uploaded_file() [function.move-uploaded-file.html]:
open_basedir restriction in effect.
File(c:\temp\php-uploads\phpD.tmp) is not within the allowed path(s): (.)
in C:\neoportal\modules\mediaalbum\mediafile_class.php on line 95

it seems that a open_basedir check is made on the source file and not only on the destination file. the file is correctly uploaded to c:\temp\php-uploads\phpD.tmp but not moved to dest folder (that is a subfolder of current dir so it's in the allowed path)

The same error is in PHPMYADMIN 2.3.3pl1 when i try to upload a file .sql

Adding the c:\temp\ path to open basedir as ".;c:\temp\" doesn't help

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-01-27 05:25 UTC] coffee at tea dot com
missing _ in open_basedir ?
 [2003-01-27 06:36 UTC] mak77 at anvi dot it
no that is my writing fault on this submission :)
 [2003-01-27 15:35 UTC] ryan at hostbaby dot com
Yeah this behavior has changed, it didn't do this in 4.2.3.  It seems like it *used to* bypass the open_basedir check when using move_uploaded_file on a file in upload_tmp_dir.  Or rather, it added one's upload_tmp_dir to open_basedir automatically (bug 17488).

Could someone comment as to whether or not this is a permanent change, and if so, perhaps document it somewhere on php.net?

(FreeBSD 4.6-STABLE Apache/1.3.27 PHP/4.3.0 apxs, safe_mode=Off)
 [2003-01-27 17:11 UTC] info at ofek dot com
yes - i have the same problem with php running as cgi in windows 2000 pro with IIS. it used to work just fine, but now with 4.3.0 i get the same error. it seems like this is a bug, because the documentation specifically says:

move_uploaded_file() is not affected by the normal safe-mode UID-restrictions. This is not unsafe because move_uploaded_file() only operates on files uploaded via PHP. 

even though open_basedir is not safe_mode i think the same logic should apply!

meanwhile i'll just add the temp dir to open_basedir is a quickfix.
 [2003-02-21 20:20 UTC] wez@php.net
It's a bug.
Streams enforces safe mode for this operation, but it should be allowed to carry on.
 [2003-02-21 20:45 UTC] wez@php.net
Please try using this CVS snapshot:

  http://snaps.php.net/php4-STABLE-latest.tar.gz
 
For Windows:
 
  http://snaps.php.net/win32/php4-win32-STABLE-latest.zip

Try the next stable snapshot.
 [2003-02-23 16:32 UTC] sniper@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-2024 The PHP Group
All rights reserved.
Last updated: Tue Dec 03 17:01:29 2024 UTC