WordPress file ownership and Permissions

[James Dugger]

As a point of further clarification, Apache is the soul user and manager
(assuming it is the only thing listening on port 80) of the http(s)
protocol requests being delivered to the server, As such it manages all
requests to other system resources on behalf of the preprocessor, in this
case WordPress in the form of PHP.   As such WordPress and by extension PHP
have no ownership on the system, they/it (PHP) passes the requests to
Apache which does have a user on the this system.  So in the context of
WordPress, Drupal, Laravel ... [insert php framework here], when it comes
to the user it is ALWAYS Apache.  In The 2 major packaged builds of Apache
in commercial use are Debian with user:group www-data, and RHEL which is
apache:apache respectively.

You should only be looking for www-data or apache depending on your
system.  Grep-ing for wordpress or some other name is a waste of time
because I doubt you went in and altered Apache to use a different name ...
cuz who would want that insanity.

When it comes to ownership and permission management of the file system
that is always the OS.  While it is common to see the boiler plate apache
ownership in the file system:
Version 1 (CentOS)
$ ls -la
drwx-r-xr--x   1 apache apache 2034 Jun 27 04:43 wp-content (for a dir)
-rw-r-xr--x  1 apache apache 2034 Jun 27 04:43 objectcache.php

you are just as likely to see this on a production server:
Version 2 (CentOS)
$ ls - la
drwx-r-xr--x   1 hosting hosting 2034 Jun 27 04:43 wp-content (for a dir)
-rw-r-xr--x  1 hosting hosting 2034 Jun 27 04:43 objectcache.php

Both of these permission and ownership versions of the same file/folder
combo will return the same with the ps command
$ ps -ef | egrep '(apache|httpd|www-data)'
root      2492     1  0 Jun27 ?        00:00:01 /usr/sbin/httpd -DFOREGROUND
apache    2636  2492  0 Jun27 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    2638  2492  0 Jun27 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    2644  2492  0 Jun27 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    2645  2492  0 Jun27 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND
apache    2648  2492  0 Jun27 ?        00:00:00 /usr/sbin/httpd -DFOREGROUND

Both versions work and both versions are valid. The difference is that in
Version 2 Apache does not have write privileges to the files.  So Why would
you do that?  Because unless your application needs to have Apache write to
files it is a security risk to do so.  Some PHP applications (Drupal)
require apache to have write privileges but only to a certain directory.
While WordPress does have proprietary plugins that require write privileges
they are usually only needed during an upgrade or initial installation of
the plugin.  This is the biggest use case by far for WordPress needing
write privileges.  In this scenario we use a CICD pipeline application to
temporarily change the permissions so Apache can write and then reset the
restrictions once deployment and installation are complete.  If the site
needs constant write privileges we usually recommend switching to Drupal or
another framework that has more robust security.  If by some unfortunate
circumstance we have to use WordPress and have to give it continuous write
privileges we point the requirement to a folder (typically a separate file
share) and try and lock down Apache with as much write limitations in the
<directory> directive in the Apache conf file for the site as possible.

We usually also do not setup SFTP in production.  Again that is what a CICD
workflow is for and that is usually done from a build agent (jenkins/bamboo
server) that has password-less SSH access and/or OAuth support.  Hosting
companies do provide SFTP access to site accounts but it is usually
dynamically instantiated at the time of the request and destroyed upon exit.

Hope the helps or maybe it was just already understood.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20190627/15486d1b/attachment.html>