Wordpress file ownership.

[blakemoore123]

Hi All,

Is there any reason why the below permissions don't work:

-rwxrwxr-- 1 ftpuser www-data 3.0K Aug 19 03:19

But these ones do?

-rwxrwxr-- 1 www-data ftpuser 3.0K Aug 19 03:19

The www-data user is in the www-group (So both ftpuser and www-data should have full rwx access to the files.)

This is set on all files in Wordpress for testing.

Cheers

[dd32]

Hi @blakemoore123 and welcome to trac :)

WordPress bases it's checks off the owner of the PHP files, mostly due to the requirement that WordPress needs to create files, in addition to writing files.

The problem is that if PHP is running as www-data/www-group and the users account is ftpuser/www-group, we have no ability (from within PHP) to know that the ftp user is actually within that group, nor do we have any ability to know that the FTP server respects the groups (There could be ACL's either at the system, or ftp level, which locks users to only owned files for example). Since WordPress wants to just-work, we can be a little more restrictive (and fall back to the fallback, FTP) to give us a much more reliable update.

Additionally, WordPress promotes increased security by encouraging hosts to utilise per-user PHP accounts to decrease the ability for cross-account site defacing and other attacks which are highly effective (When one site is infected, all others can too, etc).

So to link back to the original thing here, Files being writable for updates isn't enough since we need to create new files which we're sure the FTP user can access (and other PHP processes from other untrusted users can't modify). For places where we don't need to create new files (For example, point-release background core updates never create new files) we only require the files to be writable, so your permissions would allow for a point-release background from 4.3 to 4.3.1.

A few tickets to reference: #30245 #10205

I'm closing this as a duplicate of the above, discussion can continue without re-opening the ticket, and the ticket can be re-opened if a compromise is found which is reliable over the many different thousands of configurations WordPress experiences.

[blakemoore123]

Hi @dd32 ,

Couldn't, but if a directory has rwx for example the below:

drwxrwxr-- 1 ftpuser www-data 3.0K Aug 19 03:19 wp-content

Any user in the 'www-data' group will have access to write to the wp-content directory. All you need to do is set either ACLs or set sticky bits on the directories in questions.

Surely file permissions should be left up to the end client or a hosting providers' sysadmin (thats me in this case). If there are any errors with writing to files, just print them!

We have 10,000s of customers who don't want suPHP or php-fpm they just want mod_php and an ftp user.

If you have 10 WordPress sites on one server all writable by www-data and one gets hacked... (I understand you promote suPHP, but i don't think everyone uses it.)

I understand that this wont change, so let's agree to disagree :-)

Please can you point me to some documentation which advises how to setup WordPress with correct permissions and i can look at sending this out to my colleagues.

Cheers

[blakemoore123]

Nice to get an update on this as could do with getting things standardized.

[dd32]

Trac is not a support avenue, and any discussion can continue without the ticket being open if anyone feels like chiming in.

The following resources may include some information which is valuable to you:

• ​https://codex.wordpress.org/Changing_File_Permissions
• ​http://codex.wordpress.org/Hardening_WordPress

In short, WordPress requires FTP access in all cases except when the following conditions are met:

1. The files are writable
2. The files are owned by the current process owner
3. New files creates are owned by the current process owner

Group writable is not enough, due to #3 above, that's the crucial part, WordPress needs to be able to create files which it believes are going to be accessible by the account owner via FTP. WordPress cannot peer into the operating systems group or ACL structures, so has no idea if whatever group is assigned to the files is useful to the owner or not - for this reason, Groups are ignored entirely.
Long story short: Your hosting environment is not compatible with what WordPress supports for non-FTP upgrades.

There exists several workarounds, including writing a plugin which forces WordPress not to use FTP - this is not a recomended or supported scenario.

One exception to the above is that Automatic Background Updates can occur for WordPress core for maintenance releases as long as the files are writable, WordPress has no need to create/delete files in this situation and file attributes such as the owner or group won't change in that process.