What are the proper permissions for production use of wp cli

Question

I am running several instances of WP on GCP VMs and a test VM setup with Ubuntu 22.04 / PHP8.1 and followed the instructions at https://make.wordpress.org/cli/handbook/ to install wp cli.

The wp info output is https://paste.gnome.org/RMjEypZZJ

Running the commands as-is has read and execute but no write permissions. I tried sudo as that struck me as the thing to do but there was a nice notice about security waiting for that and when I persisted it produced a cache write error.

Following advice from other resources I created a group with apache and the current user and gave it wxr on the web root and made the current user owner and that had mixed results. sudo -u www-data works but that seems like a workaround and not the proper usage.

My question is about the exact proper permissions to maintain security and use the wp cli as intended without workarounds. Thank you.

PHP CLI works fine without these permission issues which is why I'm confused because wp cli is a phar file operating from PHP.

Answer 1

In *nix environments, the permissions and privileges of a running executable are determined by the user who executes the program. You've verified this by noticing that when you run wp-cli with sudo, what it can do changes - you didn't need to change the permissions on the executable to do this, you ran the program as root and the executable took root's privileges. This is also understandable as when you're logged in as a different user, the same executables can do different things - it's the user running the executable that changed, not the executable.

(I also note that install instructions for wp-cli don't mention anything specific re. privileges, and would if they needed to. https://make.wordpress.org/cli/handbook/guides/installing/ )

There are exceptions to this, the setuid (Set User ID) or setgid (Set Group ID) bits allow an executable take the permissions of the user or group that owns the executable, but this is probably not required here.

So, it sounds like if wp-cli does not have permission to write a file when you run it as a particular user, assuming you haven't used the setuid or setgid bits, then you may want to double double check that the user you're running it as actually has the permissions required for wp-cli to write a file, or do whatever it needs to. I suspect this is the case.

The approach here to solve your issue would be to simulate what wp-cli is doing using the user you're running it as. E.g. if you get an error that wp-cli can't write to a file in directory /var/www/foo/wp-bar, then the first thing to do is e.g. touch /var/www/foo/wp-bar/test, and this should also give the same permissions error, then resolve this using whatever setup makes sense for you in terms of the user you're running wp-cli as and apache both having write permissions to those files. SO/SE will abound with help with that, e.g. https://askubuntu.com/questions/1115979/apache-permissions-to-allow-both-user-and-web-server-to-edit-var-www

(Edit: If this approach doesn't work, then post the error from wp-cli, and the error you get from manually carrying out a similar operation using the user you ran wp-cli as, and that should give extra info to be able to resolve, however that's a general Linux permissions issue rather than specific to WP)

Answer 2

It's not WP CLI but the user that it's run as. Using sudo will give root level user access which explains why you can use sudo wp.

If using wp without sudo fails with read/write permission errors then the problem is that the user running the command is unable to read/write those files and folders. That it's WP CLI you first encountered this with is unfortunate coincidence and not something specific to WordPress or WP CLI.

Steps to take:

• run whoami to determine the user who is executing WP CLI
• run groups to determine the user groups you're in.
• Use ls -al to identify the owner and group of the files that it's struggling to write to

Either the user returned by whoami or one of the groups returned by groups needs to match with the files and folders returned by ls -al. Usually this is a www-data type user group, but if they do not match then the user can't read/write/execute, not unless the permissions on those files say that the public can do those things. That's how permissions are meant to work:

Where here:

• owner is the person who owns the file you're trying to modify. Can the owner of the file read/write/execute it?
• group is the user group that owns the file, can users who are members of that group read/write/execute it?
• public is everyone else who isn't the above, can they read/write/execute it?

It's likely that you've correctly set those files to not be writable to by public. Most users, unaware of groups, would mistakenly try to set 777 aka everyone can do everything, but the correct course of action is to ensure your SSH/terminal user is in the appropriate user groups.

Ideally your Apache/PHP workers are running as their own user, and that user and your terminal user are both in a www-data user group or equivalent so that they can both access the files, but the Apache workers/PHP have limited system access.

This is also why we can't tell you what the correct permissions are, because the answer depends on who is asking and the specific system you're asking about! The answer for me might be very different to you.