WP-CLI catch 22 with root

  • p42john

    (@p42john)


    4 years, 4 months ago

    I am working in a cPanel on CloudLinux environment and user accounts do not have shell access. I really don’t want to provide user shell access as it would open a larger potential security hole than using wp-cli as root. I am not able to use the sudo -u -i options because of the lack of user shells, and I am not able to find a good explanation on what exactly happens if you do run wp-cli as the root user, only the vague:

    When you execute WP-CLI as root, any code within your WordPress instance (including third-party plugins and themes you’ve installed) will have full privileges to the entire server. This can enable malicious code within the WordPress instance to compromise the entire server.

    That does not explain why or what exactly is the issue, just an assumption of what can happen. My question is, if I run wp-cli as the root user, and then afterwards I do a full ownership and permissions reset of the user home folder and everything in it, would that be sufficient to mitigate the problems created by running wp-cli as the root user? If not, what other steps would be necessary to reset the environment so that the WordPress install does not have full privileges on the server.

    Thank you.

    • This topic was modified 4 years, 4 months ago by Jan Dembowski.
Viewing 7 replies - 1 through 7 (of 7 total)
  • Dion

    (@diondesigns)

    4 years, 4 months ago

    You should be able to run wp-cli as user by logging in as root, then going to the correct directory to run wp-cli, and then issuing the following command:

    su -s /bin/bash user

    Thread Starter p42john

    (@p42john)

    4 years, 4 months ago

    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?

    Dion

    (@diondesigns)

    4 years, 4 months ago

    A direct answer to your question is that you can’t mitigate the security issue because PHP itself will be running as the root user, and all available PHP functions will have full access to your entire server. If you want to run wp-cli safely, you’ll need to run it as the user that owns the WordPress filesystem.

    Please try the command I suggested instead of dismissing it outright. It allows the root user to gain shell access to all /sbin/nologin users and run as that user. Once running as a new user, the exit command will return to the root user.

    For completeness, su -s will only work with the shells listed in the /etc/shells file, and the profile setup scripts will not run unless the environment .bash_profile and .bashrc files exist in the user’s “home” directory that is specified in /etc/passwd.

    Thread Starter p42john

    (@p42john)

    4 years, 4 months ago

    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 4 years, 4 months ago by p42john.
    Thread Starter p42john

    (@p42john)

    4 years, 4 months ago

    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.

    Thread Starter p42john

    (@p42john)

    4 years, 4 months ago

    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 4 years, 4 months ago by p42john.
    Thread Starter p42john

    (@p42john)

    4 years, 4 months ago

    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 4 years, 4 months ago by p42john.
    • This reply was modified 4 years, 4 months ago by p42john.
    • This reply was modified 4 years, 4 months ago by p42john.
Viewing 7 replies - 1 through 7 (of 7 total)

The topic ‘WP-CLI catch 22 with root’ is closed to new replies.