Please do not chmod 666 the wp-config.php file on installation.

[chriskuehl]

On installation, WordPress invariantly does a chmod 666 of the wp-config.php file:
​https://github.com/WordPress/WordPress/blob/4.5.3/wp-admin/setup-config.php#L393

This file is very sensitive; it contains the database password and authentication keys, among other things.

666 grants read, write, and execute permissions to every single user on the system. Even read permissions are too much; not only can you dump the database, but you can easily escalate to code execution via template changes (which are stored in the database and eval'd).

There are virtually no situations where 666 is the appropriate level of permission for this file. It should be something like 600 instead.

• On shared web hosts, other users may be able to read (or even edit!) the file, depending on what isolation the host provides. Most large shared hosting providers do it by making the home directory ~600 so that only the user can traverse it, then run the webserver as that user (and so there's no point making it 666 anyway, it might as well be 600). Other shared web hosts use suexec or suphp to achieve the same, but in these setups, 666 is incredibly dangerous and allows others to modify it (and it should be 600).

• Even on dedicated hosts with no other users or websites, these permissions mean that pretty much any compromise on the system can be elevated to full control of your site. And 600 will still work here.

If there is too much concern about this not working across diverse hosting environments, then the installer could incrementally try wider permissions until the file can be read by the PHP code (I would still argue it should never silently make files world-writable, or even world-readable, though).

Please consider changing the default to 600.

[chriskuehl]

("666 grants read, write, and execute permissions" should say just "666 grants read and write", sorry -- apparently I can't edit the description)

[Presskopp]

This file is initially created with 644 permissions, and it's a hazard to leave it like that. See Security and Hardening.

wp-config.php should be 440 or 400 to prevent other users on the server from reading it.

​https://codex.wordpress.org/Changing_File_Permissions

Component = Security?

[ocean90]

Introduced in [664].

[Presskopp]

Ok, calling this a patch is a bit vain, however..

"This file is initially created with 644 permissions". This isn't true, where does it come from?

"Patch" is setting it to 440.

Is there any argument to not set it to 440?

[chriskuehl]

Thanks for the patch! I think it should probably be 400, not 440, though. Some webhosts put multiple users in the same group (especially free shared webhosts).

Is there a case where 440 will work but 400 will not?

[dd32]

There's several arguments for why it's as it is today, although I'm not sure which ones are still valid. I wouldn't want to lower owner below 600though, as if you can write to the directory you can change the permissions anyway.

(Note: I'm specifically excluding ACLs here, they change ALL of this, and a 777 file could be a 000 file according to them)
Take the scenario where PHP is running as www-data and your FTP user is running as dd32 a 400 or 600 file would not be modifiable. If you shared the group, then 440 or 660 would allow you to (if needed) relax the permissions and modify it.
If you take the scenario where the file was created as www-data and your FTP user is running as dd32 and does NOT share a common group (not as insane as you may think it is) then 444 / 666 is suddenly the most relaxed permissions you can choose for the file.

We attempted to lower the permissions set to 640 in #20069 which failed miserably, which is why they're back at 644 for upgrades (If the permissions of index.php is > 644, such as 666 then we use 666)

I don't think there's any changes that can be made here which won't result in broken cases for a subset of users, where they won't be able to modify their wp-config.php file via FTP or control panels. These sort of issues will NEVER be seen on a *decent* host, or any test environment that we set up, it'll always be those hosts that you don't want to touch, or have never heard of that will cause pain.

One option that could work would be to utilise WP_Filesystem at this step too, which would switch to FTP in the event that the file created wouldn't be owned by the same user as WordPress. That would potentially maybe allow us to drop back to 660 or 600, as long as we included a few steps to verify that the file was still readable by the web user.

[sibprogrammer]

First of all we're talking about the new installations and about security. It seems more reasonable to make chmod 600 instead of 666. If you afraid of breaking of old hosts that will try to install the WordPress, the following steps could be made. Check the owner of PHP process and compare it with the installation directory owner. If it matches, we can do chmod 600 w/o any doubts. If the owners don't match, we can show additional checkbox on installation form saying "Allow other users (besides <detected-php-process-user>) to write to wp-config.php" (unchecked by default).

[dd32]

#45362 was marked as a duplicate.

[SergeyBiryukov]

#46409 was marked as a duplicate.