Make WordPress Core

Opened 11 years ago

Closed 9 years ago

Last modified 9 years ago

#25048 closed defect (bug) (worksforme)

file_exists check in menu-header.php causes issue with backend menu on an IIS server

Reported by: chriscct7's profile chriscct7 Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.5
Component: Administration Keywords:
Focuses: Cc:

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)

#1 @chriscct7
11 years ago

It should also be noted the existence of a second file_exists check 2 lines down from the first one.

#2 @sunnyratilal
11 years ago

  • Cc sunny@… added
  • Severity changed from normal to critical

#3 @nacin
11 years ago

  • Severity changed from critical to 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.

#4 @mordauk
11 years ago

  • Cc pippin@… added

#5 @chriscct7
11 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.

#6 @SergeyBiryukov
11 years ago

  • Component changed from Menus to IIS

#7 @nacin
11 years ago

  • Component changed from IIS to Administration

#8 @chriscct7
9 years ago

  • Keywords 2nd-opinion removed
  • Milestone Awaiting Review deleted
  • Resolution set to invalid
  • Severity changed from major to normal
  • Status changed from new to closed

Since no one's been able to replicate this, closing as invalid. If someone can reproduce this and provide replication details, feel free to reopen

#9 @chriscct7
9 years ago

  • Resolution changed from invalid to worksforme

#10 @chriscct7
9 years ago

  • Keywords dev-feedback needs-patch removed
Note: See TracTickets for help on using tickets.