Make WordPress Core

Opened 14 years ago

Closed 14 years ago

Last modified 14 years ago

#12988 closed enhancement (wontfix)

Modify wp-load.php to search for wp-config.php 2 directories higher

Reported by: chipbennett's profile chipbennett Owned by: ryan's profile ryan
Milestone: Priority: normal
Severity: normal Version:
Component: Security Keywords: wp-load, wp-config
Focuses: Cc:

Description

Currently, wp-load.php looks for wp-config.php both in the same directory as wp-load, and also one directory higher. Thus, for the default use case (WordPress installed in a subdirectory, e.g. public_html/wordpress/), wp-config.php can be placed in /public_html/wordpress/ or /public_html/.

Due to security concerns (e.g. the recent Network Solutions wp-config.php hack), it may be advantageous to move wp-config.php above the publicly accessible /public_html/ directory altogether, as such:

`/wp-config.php
/public_html/wordpress/wp-load/`

Granted, anyone who would go to the trouble of moving wp-config would probably not leave file permissions insecure. Even still, this would provide an extra layer of security for obscuring database credentials.

Attachments (1)

wp-load.php (2.6 KB) - added by chipbennett 14 years ago.
Patched version of wp-load.php

Download all attachments as: .zip

Change History (14)

@chipbennett
14 years ago

Patched version of wp-load.php

#1 @scribu
14 years ago

Note that if you did this, it would cause an extra file seek on each and every page load.

A simple workaround would be to put wordpress directly in public_html and have wp-config.php above it.

I vote for wontfix.

#2 @PeteMall
14 years ago

  • Resolution set to wontfix
  • Status changed from new to closed

sivel: "if you want to make it look somewhere custom create a wp-config.php which just includes a wp-config.php from a different location, or symlink it"

nacin: "It would only help to move it out of the web root when WP is installed in a subdirectory."

#3 @scribu
14 years ago

  • Milestone Unassigned deleted

#4 @nacin
14 years ago

My quotation actually deserves more context, as that's a relatively common setup.

Note that if you did this, it would cause an extra file seek on each and every page load.

It only would if it didn't find one at the root or one level up. Point is, any blog using two levels up means it will go through two false == file_exists checks. We could instead simply keep going one level up in search of wp-config until we hit a wall or find one.

Actually, double those numbers, as we also need to check for wp-settings.php to make sure the wp-config a level up isn't part of another WP install. So two levels up is four file exists checks on every load.

That said, I vote for wontfix. Being on one side of public_html is generally not where you need to concentrate your security on. And doing what I've suggested above is just encouraging wasteful performance. If the user is going to follow a tutorial to move wp-config up two or three or more directories, then they should instead mow down wp-config.php to just including a file up a few levels, or use a symlink.

#5 follow-up: @chipbennett
14 years ago

How is causing an extra file seek any different from the *current* wp-load, that *already* looks one directory above ABSPATH if it doesn't find wp-config at ABSPATH?

So, why is it okay for wp-load, as it currently does, to search one directory up from ABSPATH, but it would be some phenomenally huge server load for wp-load to search up one additional directory?

Nacin's argument isn't really relevant, either, since if wp-load finds wp-config at ABSPATH or one directory up, it doesn't look anywhere else. Also, the most predominant use case - by FAR, since by default WordPress unpacks itself inside a "wordpress" subdirectory - is for WordPress to be installed in a subdirectory.

By that argument, wp-load should be changed such that it doesn't look one directory up, either. It should always/only look in ABSPATH.

Regarding Scribu's argument: that suggestion is all well and good, except that, again, the vast majority of the userbase has WordPress installed in a subdirectory (which is a requirement of multisite, also), and it's a much bigger pain to migrate the entire WordPress install, with thousands of posts, comments, and pages (many of which, with attachments), out of a subdirectory into the base directory.

Finally, regarding the matter of extra file-searches: why not define a variable (similar to ABSPATH) that holds the path to wp-config, and only run the file-search if the variable is undefined? In other words, it only ever happens once, and then after that, wp-config is just included.

I think this should be re-considered.

#6 in reply to: ↑ 5 @scribu
14 years ago

Regarding Scribu's argument: that suggestion is all well and good, except that, again, the vast majority of the userbase has WordPress installed in a subdirectory (which is a requirement of multisite, also)

Quite the opposite: multisite requires that WP *not* be installed in a subdirectory.

Finally, regarding the matter of extra file-searches: why not define a variable (similar to ABSPATH) that holds the path to wp-config, and only run the file-search if the variable is undefined? In other words, it only ever happens once, and then after that, wp-config is just included.

That's an interesting idea.

#7 follow-up: @westi
14 years ago

The whole search a folder up feature was introduced for a specific use case - subversion managed installs where wordpress itself is an external.

If you were to want to place wp-config.php any higher than one directory you can easily do this by putting a dummy one in the normal place which includes the one you have stored elsewhere.

The only real benifit moving it out of public_html has is if the server stops processing php files otherwise you have no real benifit - you still need to have the file permissions correct and be on a host which stops people looking at each others files securely.

#8 in reply to: ↑ 7 ; follow-up: @chipbennett
14 years ago

Replying to westi:

The whole search a folder up feature was introduced for a specific use case - subversion managed installs where wordpress itself is an external.

So, it doesn't hurt anything to cater to that use case, because the more common use case is the first conditional. Why wouldn't that apply here, also?

If you were to want to place wp-config.php any higher than one directory you can easily do this by putting a dummy one in the normal place which includes the one you have stored elsewhere.

Not a bad solution in the short-term. But, isn't it just as server-intensive - just using an include, instead of a file-search if-statement? (I also wonder how necessary it is to verify wp-settings.php doesn't also exist with wp-config.php when searching in higher-up directories? That would be an even more esoteric use case, no?)

The only real benifit moving it out of public_html has is if the server stops processing php files otherwise you have no real benifit - you still need to have the file permissions correct and be on a host which stops people looking at each others files securely.

It may be security-through-obscurity (which isn't really security at all), but doesn't moving wp-config outside of public_html make it just a bit harder to scan for it?

#9 in reply to: ↑ 8 @sivel
14 years ago

Replying to chipbennett:

So, it doesn't hurt anything to cater to that use case, because the more common use case is the first conditional. Why wouldn't that apply here, also?

One of the topics we discussed before marking this as wontfix was "To what end?". When do we draw the line to say, ok this many directories is too many. We made the change to originally to fill a technical need and not a security need. If we decide today to allow it 2 directories up, tomorrow someone will want it three.

Not a bad solution in the short-term. But, isn't it just as server-intensive - just using an include, instead of a file-search if-statement?

Honestly, it is not as server intensive, and as far as my last comment I think this is a very valid solution.

I also wonder how necessary it is to verify wp-settings.php doesn't also exist with wp-config.php when searching in higher-up directories? That would be an even more esoteric use case, no?

The reason we check for wp-settings.php is in case that you install WP in a sub-directory of another WP install, we don't want it use the wp-config.php from the parent install.

#10 follow-up: @dougal
14 years ago

I also thought the idea of setting a variable to (optionally) define the location of wp-config was a good one. Until I thought about it a little more.

Where would we define this? The general idea is supposed to be that wp-config.php is the only file you should ever have to edit. To implement this, you'd have to modify either index.php, wp-blog-header.php, or wp-load.php directly. And we all know that modifying core files is a no-no.

About the only thing left would be to examine something in the server environment variables (set in .htaccess, perhaps?). But that doesn't translate across different web servers in a consistent way.

I'm thinking the "fake wp-config that includes the real wp-config" is the best solution for anyone who really feels the need to do something like this. Most users who know enough to want to move their config file two levels up in the first place will be capable of understanding this idea. If somebody hasn't already documented this idea on the Codex, perhaps we should.

#11 in reply to: ↑ 10 @chipbennett
14 years ago

Replying to dougal:

I also thought the idea of setting a variable to (optionally) define the location of wp-config was a good one. Until I thought about it a little more.

Where would we define this? The general idea is supposed to be that wp-config.php is the only file you should ever have to edit. To implement this, you'd have to modify either index.php, wp-blog-header.php, or wp-load.php directly. And we all know that modifying core files is a no-no.

Sorry for the confusion, but doesn't ABSPATH get defined in this way?

Why would it be such intense overhead to define a CONFIGPATH (or whatever) in the same way?

About the only thing left would be to examine something in the server environment variables (set in .htaccess, perhaps?). But that doesn't translate across different web servers in a consistent way.

I'm also intrigued by Ronald Huerca's suggestion (via Josiah Cole) of denying web access to wp-config using .htaccess - but that's outside the scope of this ticket.

I'm thinking the "fake wp-config that includes the real wp-config" is the best solution for anyone who really feels the need to do something like this. Most users who know enough to want to move their config file two levels up in the first place will be capable of understanding this idea. If somebody hasn't already documented this idea on the Codex, perhaps we should.

Yep; it seems that I'm going to have to move to this method, unless/until wp-load is ever made more accommodating.

#12 @westi
14 years ago

Fake wp-config.php is the only reasonable solution to this.

We wouldn't have added the check for a folder up like we did if it wasn't for the strong subversion managed install use-case - in that scenario a fake wp-config.php just wouldn't work.

Don't forget moving wp-config.php outside public_html doesn't improve the security of the file.

It will only protect you if the server stops processing the file as a php file.

Where ever the file is the server security configuration and the file permissions still need to be set correctly to adequately protect the information within.

#13 @strider72
14 years ago

"Sorry for the confusion, but doesn't ABSPATH get defined in this way?"

ABSPATH is properly defined in wp-load.php. It is conditionally defined in wp-config.php for backwards compatibility with plugins that call wp-config directly. Plugins should not do this, but many do anyway.

Note: See TracTickets for help on using tickets.