WordPress Prompting for FTP Credentials

If you just want to see my recommended permissions for a DocRoot, that is here.

When updating plugins, themes, or the WordPress core – or when activating WordFence (and possibly in other situations), you may be prompted for FTP credentials for the webserver. If so, this indicates that WordPress was not able to write to the server. These are the things to check:

Ownership

Is the the Apache user the owner of all files in the site’s document root?

# To check owner and group (owner:group)
ls -lh

There are security concerns with having the Apache user be owner of the entire Document Root, especially if multiple sites are hosted on the same server. Best practice is to make your user the owner, and a group which the Apache user is a part of the group.

# Change ownership (-R switch makes recursive)
chown -R myuser:apache /var/www/html/foldername

This breaks in-browser updates though because WordPress checks if it (or specifically, the PHP processor running under the Apache user) can write to a folder, and that the file it writes has the same owner as the other WP files. When Apache creates a new file, its user will be the owner (apache:apache). This will mismatch other WP files (myuser:apache) and the test will fail, resulting in WP asking for FTP credentials.

As I understand it, setting FS_METHOD to direct (as referenced at the end of this) will bypass this check, and is the reason that is often proposed as the ‘fix’ for this since permissions can be set to allow for the group to write access for the file, even though the checks performed by WP fail. Why doesn’t WP change the way they test? I don’t know. The test failing even though permissions are loose, or the test changing to allow for looser permissions both ignore the same thing: permissions are loose.

So, to allow for plugin updates, we want to change ownership just for the areas we want WP to be making changes to files – inside the wp-content/ folder.

chown -R apache:apache /var/www/html/foldername/wp-content

This way; plugins, themes, and media can all be uploaded in the browser.

Unfortunately, I think this will still not allow WP to update the core in-browser, or by auto-update. Presumably there is a secure way to allow this, but also how can there be? Maybe auto-update was added and is encouraged since many sites have bad owner/permission configurations?

Permissions

Are the rwx permissions on the files set properly?

# When we want both ourselves as server admins and WP
# as the Apache user to be able to write files (places where it is apache:apache, eg wp-content/)
find . -type f -exec chmod 664 {} +
find . -type d -exec chmod 775 {} +

# When we want higher security, and to only allow WP
# as Apache to read files, but not write them (where it is myuser:apache, eg most of the DocumentRoot)
find . -type f -exec chmod 644 {} +
find . -type d -exec chmod 755 {} +
chmod 640 wp-config.php

# For our own files that are in there, but are not part of WP (like .gitignore, etc)
chmod 600 .gitignore

Security Enhanced Linux

If on RHEL or CentOS (or other distro with SELinux) do the files have the correct security context?

# To check security context
ls -Z

# Copy context from one file to a another (add -R to make recursive, and apply to folders)
chcon --reference=/path/to/desiredcontext/file /path/to/contexttochange/file

# Set context to known value
chcon unconfined_u:object_r:httpd_sys_rw_content_t:s0 /path/to/file

To turn off SELinux temporarily for testing purposes:

# check SELinux status
getenforce

# turn off SELinux until next rebott
sudo setenforce permissive

# turn on SELinux
sudo setenforce enforcing

Dev Only

As last resort, and only in dev (considering security concerns), force WordPress to try despite its test failing by confirming this line is present in wp-config.php, and adding it if it is not present? src

define('FS_METHOD', 'direct');