What if the error read:

Internal Error: Could not rename file "/tmp/phpO39LcP" to
"$ImagePath/f/fb/AmitmcfserumQC.pdf"

Would make more sense the person administrating the site, but doesn't reveal any private info.

webmaster wrote:

I bumped into this as well.
To resolve it, I ran:

chmod -R 777 /var/www/vhosts/example.com/wiki/images

I don't like opening it all the way up, but nothing else worked.

Relevant reading:
http://lists.wikimedia.org/pipermail/mediawiki-l/2008-April/027074.html

fran wrote:

Fixed in r39608. :) The above error should now look like:

Internal Error: Could not rename file "{wfTempDir()}/phpO39LcP" to
"$wgUploadDirectory/f/fb/AmitmcfserumQC.pdf"

This should hopefully be less confusing for users and administrators, while still not leaking out path data, which appears to have been the rationale behind the public/ pseudo-paths.

This was reverted in r39652

Brion, could you take another look at this? I think you missed the discussion here when you reverted the patch (probably because the bug ID wasn't included).

Well, A) it looks kind of icky and B) I don't think $ is banned from filenames, so $IP or $wgUploadPath etc may appear in literals, breaking the replacements. Additionally note we don't want to expose full pathnames by default as this is a general server security issue.

It doesn't do replacements: it uses single quotes. All it does is change the confusing 'public/path/to/file' to the less confusing '$wgUploadDirectory/path/to/file'; the full path is not revealed.

michael.daly wrote:

Simple -

if user groups includes "admin"{

Show full path.

} else {

Explain the problem in plain language so anyone can have some margin of hope in understanding it.  
Dump the real problem to the error_log so that it gets reported to the admin.

}

Provide a config parameter to enable this for admins if you think that letting *any* admin see the real path is too much risk. That allows the site's main admin to decide instead of WMF.

Maybe an error reporting level is due - warn, error, imminent death... so that error logs can be controlled.

I think a better algorithm would be:
<code>

Explain the problem in plain language so anyone can have some margin of hope

in understanding it.

Dump the real problem to the error_log so that it gets reported to the admin.

if user groups includes "admin"{

Show full description .

}

</code>

But, what if the admin can't reproduce it?
The admins/people doing support may be guided just by the provided error message.
That's specially true for shared hosts where doesn't have access to the error log.

Also, some users are more clueful than admins. :)

michael.daly wrote:

The error log should be set to the disk space allocated to the wiki site. This assumes a "local" php.ini from the host for each hosted service. Many hosting services provide for this; if the service doesn't provide this, get a better hosting service. That's the advice we repeatedly give on msusers.com.

Sure they can change hosts, or set display_errors.
But they aren't the best answer. I'm only anticipating that we'll get users with that problem that are unable to explain what the error is (and not being admins on their wiki, we won't be able to read it, either).

(In reply to comment #2)

I bumped into this as well.
To resolve it, I ran:

chmod -R 777 /var/www/vhosts/example.com/wiki/images

I don't like opening it all the way up, but nothing else worked.

Relevant reading:
http://lists.wikimedia.org/pipermail/mediawiki-l/2008-April/027074.html

This might help close that back down again:

http://www.mediawiki.org/wiki/Manual:Security#Upload_security

(In reply to comment #6)

Additionally note we don't want to expose full pathnames by default as this is
a general server security issue.

Given that image magick already does this (for PNG's anyhow), its not like the info isn't already released. [of course people might not be using image magick, might have it configured differently, etc]