Last modified: 2012-01-06 22:55: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 13812 - Upload errors display pseudo-paths with 'public', confuse users
Upload errors display pseudo-paths with 'public', confuse users
Status: REOPENED
Product: MediaWiki
Classification: Unclassified
Uploading (Other open bugs)
unspecified
All All
: Low minor with 2 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
http://lists.wikimedia.org/pipermail/...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-21 18:17 UTC by Brion Vibber
Modified: 2012-01-06 22:55 UTC (History)
8 users (show)

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


Attachments

Description Brion Vibber 2008-04-21 18:17:27 UTC
Common upload errors such as permissions problems display error messages like this:

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

The use of the 'public' pseudo-path here confuses the heck out of users, who naturally enough look for a 'public' directory and can't find it, since they don't know the secret that 'public' isn't a real directory, but a reference to $wgUploadDirectory which is usually called 'images'.

Either the path should be transformed to a filesystem path here, or it should be otherwise broken down into comprehensible parts.
Comment 1 Chad H. 2008-04-22 13:07:37 UTC
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.
Comment 2 Jamie Hari 2008-08-14 03:52:41 UTC
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
Comment 3 Fran Rogers 2008-08-18 20:17:51 UTC
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.
Comment 4 Chad H. 2009-03-11 20:44:52 UTC
This was reverted in r39652
Comment 5 Emufarmers 2009-05-23 01:16:45 UTC
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).
Comment 6 Brion Vibber 2009-05-27 17:21:38 UTC
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.
Comment 7 Emufarmers 2009-05-27 19:19:53 UTC
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.
Comment 8 Michael Daly 2009-05-27 22:25:55 UTC
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.
Comment 9 Platonides 2009-05-27 22:37:39 UTC
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. :)

Comment 10 Michael Daly 2009-05-27 22:52:56 UTC
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.
Comment 11 Platonides 2009-05-27 23:12:05 UTC
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).
Comment 12 badon 2012-01-06 22:52:08 UTC
(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
Comment 13 Bawolff (Brian Wolff) 2012-01-06 22:55:20 UTC
(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]

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


Navigation
Links