Last modified: 2013-03-25 14:06:22 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 1665 - open_basedir restriction prevents uploading of images
open_basedir restriction prevents uploading of images
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
1.4.x
PC Linux
: Low normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-03-09 00:54 UTC by Kyle
Modified: 2013-03-25 14:06 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Kyle 2005-03-09 00:54:56 UTC
[Just a side note, this is the second time I've typed this up. The first time I
entered all of this in and Commit'd it, MediaZilla had an issue with my
submission and told me to press Back on my Browser (FireFox). I did so, and was
prompted regarding the sending of POST DATA, and etc. I clicked Okay, and I was
presented with this form again, but instead of all the text I had entered, each
field was reset to its default value: blank. Wonderful]

I've managed to isolate 3 bugs in regards to uploading images on a system in
which open_basedir for vhosts is in effect. 

/include/

638    $data = @getimagesize( $tmpfile );
682    $file = fopen( $filename, 'rb' );
716    $file = fopen( $filename, 'rb' );

Line 638 was the most difficult to locate, since error information is being
suppressed by the @ operator. 

I could write up a patch with some code for this, but I have not yet had the
time to examen MediaWiki's code base. I did however manage to bypass these
problems by simply commenting the blocks of code that they involve, but this is
not a solution.

Perhaps the best idea would be to use the move_uploaded_file() function to
relocate the file to a MediaWiki temporary directory that exists within the
open_basedir path. After that, the verification procedures will work without
trouble.
Comment 1 Kyle 2005-03-09 00:56:54 UTC
I forgot to specify the file that those lines exist in. The file is
'includes/SpecialUpload.php'.
Comment 2 Peter Linss 2006-03-05 20:10:59 UTC
I just patched my copy of MediaWiki with a fix for this issue.

In includes/SpecialUpload.php:
@@ -78,6 +78,13 @@
                         *Check for a newly uploaded file.
                         */
                        $this->mUploadTempName = $request->getFileTempName( 'wpUploadFile' );
+      { /* Move uploaded file to temp folder to bypass open_basedir restrictions */
+        global  $wgTmpDirectory;
+        $safeFilePath = $wgTmpDirectory . '/' . basename($this->mUploadTempName);
+        if (move_uploaded_file($this->mUploadTempName, $safeFilePath)) {
+          $this->mUploadTempName = $safeFilePath;        
+        }
+      }
                        $this->mUploadSize     = $request->getFileSize( 'wpUploadFile' );
                        $this->mOname          = $request->getFileName( 'wpUploadFile' );
                        $this->mSessionKey     = false;

and change existing uses of move_uploaded_file to rename:
@@ -336,7 +343,7 @@
                        }
                } else {
                        wfSuppressWarnings();
-                       $success = move_uploaded_file( $tempName, $this->mSavedFile );
+                       $success = rename( $tempName, $this->mSavedFile ); // was move_uploaded_file
                        wfRestoreWarnings();
 
                        if( ! $success ) {
@@ -367,7 +374,7 @@
                $archive = wfImageArchiveDir( $saveName, 'temp' );
                $stash = $archive . '/' . gmdate( "YmdHis" ) . '!' . $saveName;
 
-               if ( !move_uploaded_file( $tempName, $stash ) ) {
+               if ( !rename( $tempName, $stash ) ) { // was move_uploaded_file
                        $wgOut->fileCopyError( $tempName, $stash );
                        return false;
                }

This moves the uploaded file to $wgTmpDirectory before performing the validity tests. You'll need to be sure that 
$wgTmpDirectory is set to a valid writable directory.
Comment 3 Brion Vibber 2006-03-05 22:12:17 UTC
IIUC this allows injection of unvalidated files into the web root.
Comment 4 Peter Linss 2006-03-25 18:46:12 UTC
True, it could place an unvalidated file into the web root if $wgTmpDirectory is located within the web root, which it need not 
be, but is by default. At the least, code should be added to delete the uploaded file if validity checks fail or if any other error 
prevents the final move into the final location. This will also avoid relying on some external mechanism to clear out the temp 
folder and could prevent disc allocation problems on servers with space restrictions.
Comment 5 Andre Klapper 2013-01-03 19:08:34 UTC
(In reply to comment #2)
> In includes/SpecialUpload.php:

According to the last change in June 2008 at
https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=history;f=includes/SpecialUpload.php;hb=HEAD this file was moved to
   includes/specials/SpecialUpload.php

Looking at the current codebase at https://gerrit.wikimedia.org/r/gitweb?p=mediawiki/core.git;a=history;f=includes/specials/SpecialUpload.php;hb=HEAD there is no mention of a move_uploaded_file function anymore that you had trouble with in MediaWiki 1.4.

Hence this bug report is very likely obsolete - at least the workarounds mentioned here are.
Comment 6 Andre Klapper 2013-03-25 14:06:22 UTC
No feedback, so I'm closing this as obsolete. Please reopen if it's still a problem in a recent version.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links