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.

ramiller wrote:

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 (http://www.php.net/): 4.3.10-16 (apache2handler)

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.)

ramiller wrote:

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/yoper.com/www/wiki/.htaccess. 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.