(In reply to comment #0)

In img_auth.php, $path is being set to a value that includes 'img_auth.php' at
the beginning of it.

What value does it get set to?

MediaWiki wrote:

(In reply to comment #1)

What value does it get set to?

Adding a couple debugging lines to img_auth.php@45112b89 (I use the GitHub mirror) dated 2011-11-20, I get:

$matches = Array
           (
               [title] => img_auth.php/a/ab/File_name.ext
           )
           1
$path = img_auth.php/a/ab/File_name.ext

The extra bit at the beginning makes the realpath() call on Line 71 return false (see https://github.com/mediawiki/mediawiki-trunk-phase3/blob/797386c6fa75a3c4d239c8ebcd2f6c796f512f8e/img_auth.php#L71 )

That in turn makes $filename = '' (empty) and so the directory traversal check on L75 fails.

This is all because WebRequest::getPathInfo() is returning the filename of the calling script along with the actual PATH_INFO data.

Hope that helps. I don't really understand WebRequest too well, and I don't have time to dig until later this week.

By any chance is your $wgArticlePath set to "/$1"?

If so, and you're accessing urls like "http://wiki.example.com/img_auth.php/a/ab/File_name.ext" then it sounds like MediaWiki is interpreting that url as an article path since the script you're using is not index.php.

We may want to add handling that will intelligently understand what the real .php file being referenced in the URL is and make use of that instead of ONLY checking for $wgScript. If not auto-detection then maybe we should add a $wg variable that lists all known php script paths. Then we can add img_auth.php and api.php to it, users who do things like i.php can add both to it, and extensions that define new .php files can add theirs as well in case.

MediaWiki wrote:

(In reply to comment #3)

By any chance is your $wgArticlePath set to "/$1"?

Yes, it is. The relevant config block:

$wgScriptPath       = "";
$wgScriptExtension  = ".php";
$wgScript           = "$wgScriptPath/index.php";
$wgArticlePath      = "/$1";

I don't remember having this problem the last time I set up a personal wiki site, but then again that was with version 1.11 or so. (I was also using a stable release, instead of checking out the latest development version every so often.)

Current .htaccess:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !\.[a-z]{2,4}$ [OR]
RewriteCond %{REQUEST_FILENAME} [:]
RewriteCond %{REQUEST_FILENAME} !^(index|img_auth|api)\.php
RewriteRule (.*) index.php?title=$1 [NC]

Is there a different .htaccess configuration that will avoid this issue? (I'd rather that than keep rewriting img_auth.php)

We may want to add handling that will intelligently understand what the real
.php file being referenced in the URL is and make use of that instead of ONLY
checking for $wgScript. If not auto-detection then maybe we should add a $wg
variable that lists all known php script paths. Then we can add img_auth.php
and api.php to it, users who do things like i.php can add both to it, and
extensions that define new .php files can add theirs as well in case.

That sounds like a good idea in theory, but wouldn't it have the potential for causing problems if someone wants a page in NS_MAIN that has the same name as a core file listed in that array?

(In reply to comment #4)

(In reply to comment #3)

By any chance is your $wgArticlePath set to "/$1"?

Yes, it is. The relevant config block:

$wgScriptPath       = "";
$wgScriptExtension  = ".php";
$wgScript           = "$wgScriptPath/index.php";
$wgArticlePath      = "/$1";

I don't remember having this problem the last time I set up a personal wiki
site, but then again that was with version 1.11 or so. (I was also using a
stable release, instead of checking out the latest development version every so
often.)

Current .htaccess:

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !\.[a-z]{2,4}$ [OR]
RewriteCond %{REQUEST_FILENAME} [:]
RewriteCond %{REQUEST_FILENAME} !^(index|img_auth|api)\.php
RewriteRule (.*) index.php?title=$1 [NC]

Is there a different .htaccess configuration that will avoid this issue? (I'd
rather that than keep rewriting img_auth.php)

We may want to add handling that will intelligently understand what the real
.php file being referenced in the URL is and make use of that instead of ONLY
checking for $wgScript. If not auto-detection then maybe we should add a $wg
variable that lists all known php script paths. Then we can add img_auth.php
and api.php to it, users who do things like i.php can add both to it, and
extensions that define new .php files can add theirs as well in case.

That sounds like a good idea in theory, but wouldn't it have the potential for
causing problems if someone wants a page in NS_MAIN that has the same name as a
core file listed in that array?

:/ Your config better not be serving [[Api.php]] for /api.php

MediaWiki wrote:

(In reply to comment #5)

:/ Your config better not be serving [[Api.php]] for /api.php

Nope. :) http://wiki.technobabbl.es/api.php

I committed some changes to the WebRequest and img_auth.php handling code in r104150. Could you tell me if that change fixes this bug?

MediaWiki wrote:

Tested and found to be behaving on my test wiki.

Appears fixed by r104150

*** Bug 34042 has been marked as a duplicate of this bug. ***