File vs. directory permissions

[mbrowne]

I came here from your helpful blog post (thanks!):
https://jakebillo.com/wordpress-file-permissions-and-upgrades-with-wpfix-py/

I am running a server hosting a website managed by someone else and I want to allow him to perform updates automatically in Wordpress rather than having to use the command line.

One thing I don't understand about your blog post and script is why you suggest to change only file permissions rather than running this command which seems simpler:

chmod -R g+w wp-{admin,includes}

That makes directories group-writable as well, but if all the files are writable I don't see why there would be any additional security risk in making directories writable too...is there some advantage I'm missing?

One other nitpick: a naiive reader of your blog post might try to run a command like this:
chmod -R 664 wp-admin

...which would obviously be problematic in terms of being able to list directory contents. As I said, a nitpick, and maybe not worth correcting since you did after all say "files", not "files and directories".

Anyway, it's too bad that it seems like the only way to get this working correctly (without installing suexec) is to do updates manually or using the command line...although I am using the "SFTP Updater" plugin so updates are installed via SFTP rather than FTP - maybe that's why it didn't work?

Thanks and sorry for the long-winded questions; there isn't much good info on how to set this up correctly for VPS servers and your blog post and library is one of the few good resources I found...

[jbillo]

Hi Matt,

Appreciate the feedback on the post. I had a few things in mind when initially writing it and the script, which may not be relevant any longer. I'll try to go over some of my thinking and answer your questions as best I can.

For background, right now for the sites I manage, I actually have a Nagios plugin that detects when WP core, plugins or themes are out of date. On the first check failure, it kicks off a variant of https://github.com/jbillo/scripts/blob/master/wpupdate.sh and handles the upgrade of all components automatically. There are downsides with this method too (some people have very version-specific plugins) but since I'm well aware of the widespread availability of plugin and WordPress exploits, I generally tell those users that it's for their own good.

With respect to file permissions under wp-content, my thought was really only to touch directories that absolutely needed it. Theoretically you could have other directories provided by plugins outside of {plugins,themes,uploads,upgrade} in $SITEROOT/wp-content, and I know some of the caching ones complain if you give those directories more permissive write options.

The script originally began as a way to just reset things - to bring all files in the WordPress tree back to a known state (dirs at 755, files at 644) before beginning the (optional) g+w type operations. There was also an idea that perhaps allowing writes to wp-content and wp-admin was not entirely desirable and could be excluded with a different flag. I'm thinking something like a "plain text" style website that gets updated with the CLI, and the user doesn't have the need or get the permission to upload media or add plugins through the UI. Might be a bit far-fetched, but that was the original scenario.

Anyway, that's why I do the find commands initially, then later add g+w to wp-content later. Really, the script badly needs a refactor to use argparse, sort out some of the filesystem issues, and perhaps add an interactive mode with "what do you want" style questions.

You're right about the chmod -R 664 wp-admin possibility; I'm going to update the post to be a bit more clear about only applying that permission to files and giving an example command.

I suspect that whatever updater plugins are in place, they will also run under the same permissions as the webserver (since they're invoking PHP code) whereas if you were to use a client and connect to the FTP/SFTP daemon, you'd be logged in as the user account (direct owner of the files) with all the delicious write permissions that said role entails.

In the future, I think Docker plus a reverse nginx proxy to each hosted WordPress site might be useful for something like this (that way the user and group can own everything, and the nginx/apache group is specific to only that website), but that's additional resources used and I'm also skeptical that a Docker container wouldn't be subject to other security concerns.

[mbrowne]

Thanks for the detailed reply. So it sounds like in spite of the misleading Wordpress documentation, the only way for core updates to be installed from within Wordpress is to either relax the permissions or to use some other solution where the web server user is the same as the FTP user, e.g. suexec or your nginx proxy idea.

I think the Docker solution could work, but I think that Docker would probably be mostly of interest to developers who are already comfortable with the command line anyway. I'm guessing that could work regardless of what server was used within Docker? It's a little funny when you think about the fact that nginx is capable of running PHP on its own...it would be nginx delegating to Apache or nginx delegating to nginx (the latter within the Docker container)...