![(please configure the [header_logo] section in trac.ini)](/chrome/site/your_project_logo.png){kind=logo}
#25048 closed defect (bug) (worksforme)
file_exists check in menu-header.php causes issue with backend menu on an IIS server
| Reported by: | chriscct7 | Owned by: | |
|---|---|---|---|
| Priority: | normal | Milestone: | |
| Component: | Administration | Version: | 3.5 |
| Severity: | normal | Keywords: | |
| Cc: | Focuses: |
Description
On line 153 of menu-header.php (based on 3.6 branch), a file_exists check wreaks havok on IIS powered servers.
Let's say $sub_file is either a full url to the intended page, or a admin.php page slug, both valid values for that varible.
In an Apache server, the file_exists, returns false, and WordPress continues along, making the link, which works fine.
On Windows IIS servers, however, the file_exists, when fails, indirectly throws a PHP warning. A good number of Windows based servers use an open_basedir restriction to prevent people from accessing areas they aren't supposed to be in. So, when the filepath inside that file_exists is outside what the user is supposed to be able to access, where the menu item would be, is a PHP warning.
A suggested fix would be to make sure $sub_file is a file (ending in a .php) before running a file_exists check on it.
Issue first detected in 3.5, but probably exists earlier than that (didn't check)
Change History (10)
#3
@
13 years ago
- Severity critical → major
A warning is major, but I don't think it is critical.
Could you provide some code that would trigger this warning if run on IIS with an open_basedir restriction? Could you supply a sample open_basedir value to trigger this? If the right open_basedir restriction were set on an Apache server, is this similarly trigger-able?
The two checks are within WP_PLUGIN_DIR and ABSPATH — surely open_basedir should include the web root. Otherwise WordPress is in trouble for other reasons.
I am curious why this has not been previously reported — sounds not uncommon for $sub_file to not be a file.
#5
@
13 years ago
@nacin My bad for not getting back to this. Forgot which is my fault.
I just assumed it was an open_basedir restriction created issue based on the error that looks like this:
open_basedir restriction in effect. File(C:\Inetpub\vhosts\domain.com\sitedir/wp-content/plugins/http://mysite.com/wp-admin/edit.php) is not within the allowed path(s): (C:\Inetpub\vhosts\domain.com\sitedir\) in C:\Inetpub\vhosts\domain.com\sitedir\wp-admin\menu-header.php on Line 151
Unfortunately, I'm not really a Windows server person, so I can't explain why this didn't get reported by others but it still seems like something that should be patched
I look around for some wp.org tickets like this if you want. Not sure if it'd help or not.
It should also be noted the existence of a second file_exists check 2 lines down from the first one.