Last modified: 2006-02-01 04:46:20 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 4692 - "The file is corrupt or has an incorrect extension..." error
"The file is corrupt or has an incorrect extension..." error
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
PC Linux
: Low minor (vote)
: ---
Assigned To: Nobody - You can work on this!
Depends on:
  Show dependency treegraph
Reported: 2006-01-20 16:18 UTC by Reid Miller
Modified: 2006-02-01 04:46 UTC (History)
0 users

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


Description Reid Miller 2006-01-20 16:18:14 UTC
I have been wrestling with this issue for some time now. The Mediawiki version
is actually 1.4.14, but this has been an issue for some time now. When a user
tries to upload an image (png, jpg, gif), we're not trying to do anything weird,
they get a "The file is corrupt or has an incorrect extension. Please check the
file and upload again." error. I've read the FAQ:

To troubleshooot I'd temporarily set $wgVerifyMimeType = false; in
LocalSettings.php That did not help. I've explicitly set $wgFileExtensions =
array('gif','png','jpg','jpeg'); in LocalSettings.php That did not help. The
directory permissions are chmod -rwx for owner and group, but nothing for
others. I've asked in #mediawiki about this issue, verified a few test files
were not corrupt using the program xv (which they said was good at verifying the
validity of a file). Still I get these errors. I've doublechecked the Whitelist
and Blacklist in DefaultSettings.php I'm really out of ideas.
Comment 1 Brion Vibber 2006-01-20 21:00:40 UTC
Confirmed on your system.

Can you check if PHP's 'open_basedir' option is on? This usually makes it impossible
for the program to open the file and check it for validity before saving it.
Comment 2 Reid Miller 2006-01-21 06:34:38 UTC
Thank you for responding. I checked up on a few things tonight with our web
host. I double checked to make sure that our upload directory was writable by
the web server and it was not. He set it to be writable by the web server
though, so that should be corrected now. I was incorrectly assuming that before.
I also had him check on php's 'open_basedir' option. We cannot turn the
'open_basedir' restrictions off because we are not the only site on that box.

So, from this point... I thought to myself, well as long as the upload directory
is writable by webserver, uploads should work as long as all file checks are
off. I would not plan to leave it this way, because of security issues but I
wanted to troubleshoot so I set all these things in LocalSettings.php:

$wgVerifyMimeType = false;
$wgStrictFileExtensions = false;
$wgCheckFileExtensions = false;

I would assume now that all checks on the file are off, and as long as the
upload directory is correctly writable by the web server it should have worked.
No such luck. When doing my upload tests I made sure to log out of my account,
log back in and throw a ?action:purge in the URL before the upload just to make
sure the cache and was cleared and things. Are there any other things I can try,
or because of our situation with the web server and 'open_basedir' needing to be
left on, am I out of luck? Thank you for what you've done already though.

Additional Info: PHP ( 4.3.10-16 (apache2handler)
Comment 3 Brion Vibber 2006-01-21 07:24:28 UTC
MediaWiki does security checks on uploaded files to prevent files being uploaded
that would trigger HTML autodetection in Internet Explorer. This could be used
as a cross-site scripting vector to hijack accounts on the wiki.

With PHP's ham-handed open_basedir on, unfortunately, the file can't be examined
while it's still in the system temporary directory.

If you hack up the code in SpecialUpload.php, you could perhaps disable this
(not recommended, as it opens your users to the IE exploit) or move the files
to a temporary directory first. (If you do so, you may wish to carefully lock
down that directory from web access.)
Comment 4 Reid Miller 2006-02-01 04:46:06 UTC
My web host adjusted some things to accomidate for us. Every second level user
on the box now runs under its own user, even php-scripts. Many link use a URL
scheme wich only work, if php is used as apache.module: index.php/foo/bar. In
cgi-mode this doesn't work. But he fixed this issus with a rewrite rule defined
in /var/www/ This redirects accesses to
index.php/foo/bar to index.php?title=foo/bar transparently.

So my problem is now solved, thank you for helping narrow down the specific
problem. I wish there was a nice way for me to add this into the FAQ... hrm I'll
think about a way to generalize and account for this info there, as there's
nothing along these lines there currently. This incident can be closed.

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