p42john

Happy to report that I finally got a wp-cli command to work using su. Here again it was the security of my hosting environment that needed to be dealt with, and I fear that the solution is no more secure than running wp-cli as root.

The issue that was causing the listings to be severly limited and preventing the shell user from finding the wp binary was the CageFS: https://docs.cloudlinux.com/cloudlinux_os_components/#cagefs

To circumvent this I created the file /etc/cagefs/custom.proxy.commands and added WP=/usr/bin/wp then ran cagefsctl --update.

The upside of this is that I can now run wp-cli commands, for example:
su -s /usr/bin/bash userx -c 'cd /home/userx/public_html && wp post list'
will now properly output a result.

However, the downside is that I am now allowing wp-cli to run outside of the user jail. I would need allot of convincing that this is somehow better than using --allow-root, especially since I have yet to get an explanation of exactly what doing so does, and my observations lead me to believe it is no more than create files and folders with root user and group ownership. This would be my third time in this thread stating how trivial it actually is to reset the ownership and permissions. It would be really nice to just get a straight answer to my original question in the original post.

• This reply was modified 3 years, 1 month ago by p42john.
• This reply was modified 3 years, 1 month ago by p42john.
• This reply was modified 3 years, 1 month ago by p42john.

Well, I did find a large issue with using su. It seems that when I use it the environment is vastly different. Something as simple as a directory listing shows it. If I am root and I do ls /usr/bin I get a full listing. If I rather do su -s /bin/bash userx -c 'ls /usr/bin' I get a small fraction of the files listed. Maybe about 10%

I discovered this when attempting to call wp because I was getting bash: wp: command not found and it is a bit hard to run a command you don’t have access to.

• This reply was modified 3 years, 1 month ago by p42john.

I am adding this in case it helps anyone who finds this thread.

Although I strongly suspect that using --allow-root would work and still be safe as long as you reset the ownership and permissions to be correct for the user. I don’t want to do this without confirmation that is the only thing that gets changed in using the --allow-root option.

This is what I use on my cPanel servers for said ownership and permissions resets. It is specific to cPanel, to it does it intelligently.
https://github.com/PeachFlame/cPanel-fixperms

I have experimented with the method mentioned by @diondesigns and have found that if I add the -c option I can have it run a specific command as that user, using the specified shell. This provides a way to run a command in a script non-interactively. I suspect if I bundle all the wp-cli commands that I need to run into a script that I call from the script I am running, I can call it from the su command and have it’s contents run as the intended user.

I still need to do some experimenting, but in my preliminary test of having it create a file with touch in the user’s home directory, it did create the file with the user and group of the intended user.

From here anyone with the same question should have what they need to create a script in a no user shell environment that properly runs with the user permissions. Obviously this is only relevant to service providers and self hosting, and not to people using shared hosting. If I run into any unexpected surprises in getting this to work, I will report back.

PHP never runs as root on the server. It seems maybe whoever wrote these warning might not have an understanding of the hosting environment. The PHP can only ever be run by the web server via the module that runs it for the server thread that calls it. Only users and never root can create those threads. If a thread is created by userx and it tries to read a file under /home/userx/public_html/… which is either not owned by userx or has too permissive file permissions such as 777, then the web server will throw a http 403 Unauthorized error. There seems to be a lot of bad assumptions to the “big scary warning” that is given and your statement that “WP itself will be running as the root user” is simply not true.

Also, su -s /bin/bash user is only going to work in an interactive environment. It is worthless for using within a script. In my own experiments on a user that was in dev for testing and could be deleted I tried it with the --allow-root option. From my observations all it did was change the owner and group to root for the affected files. This is very easy to rectify.

Why is it so hard to simply say the owner and group get changed and file and folder permissions would need to be reset? I’m starting to think that it is more about protecting and maintaining “Big Scary Warning” and less about actually providing an honest answer about that happens when you run with --allow-root. as far as I am able to tell thus far, the only thing it does is change ownership of files.

• This reply was modified 3 years, 1 month ago by p42john.

Telling me how I should be able to get a user shell after I stated that user shells are not available does not provide an answer to my question, nor a useable solution.

Does anyone know the answer to the question I quite directly asked?