Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!


Need help with WordPress permissions on server
New on LowEndTalk? Please Register and read our Community Rules.

All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.

Need help with WordPress permissions on server

I have lots of WordPress installations on one of my servers. Before they was split on three different VPSs, but now all is at one server.
My issue is when it comes new security updates, 4 of my installations do update automatically, the rest don't. Thats apply to main wordpress versions, and plugins and themes.

Beside themes I want everything to auto update, or that I can just press update in the control panel (for plugins/themes).

The real issue here is file/folder permissions. My folder has 755, and my files has 664. And then the update don't work. When I set the file/folder permission to 775 it works. And after the update, the permissions is automatically set back to 755 and 664.

How can I fix this issue? I want all major and minor updates to WordPress to automatically be installed. Not just the 4 installations that get it today.
And I want to press update on plugins and themes and get them updated.

Can a script solve the last issue. A script that I can run (bash) before I start updating?
How will that script look like? I can only change file/folder permissions on files and folders that's need updating, or the settings will be 775 on all folders and files. That's a security risk?

And how to solve the first issue, that WordPress always is updated on all sites?

«1

Comments

  • I think you have to change the ownership of the files. Maybe someone can tell more on this.

    Thanked by 1myhken
  • What plugins are being used on that installation and is it a basic lamp stack or using control panels?

    Each and every one of your wordpress install configured the same way?

    Thanked by 1myhken
  • @WHT @seriesn

    I think you have to change the ownership of the files. Maybe someone can tell more on this.

    The ownership is the user of the site, so that's correct.

    What plugins are being used on that installation and is it a basic lamp stack or using control panels?

    Just Akismet and Jetpack. And I use Virtualmin on CentOS 6.8 64bit

    Each and every one of your wordpress install configured the same way?

    Yes

  • jarjar Patron Provider, Top Host, Veteran

    myhken said: The ownership is the user of the site, so that's correct.

    Is it the user that PHP is executing the code as?

  • All files related to WordPress must be owned by the same user who also owns the PHP process (in the case of PHP-FPM) or the Apache process (if you're using mod_php).

    If you aren't using any control panel try one of the following:

    On PHP-FPM:

    chown -R www-data:www-data /path/to/document/root
    

    On Apache (Debian variants):

    chown -R apache:apache /path/to/document/root
    

    Apache on CentOS:

    chown -R httpd:httpd /path/to/document/root
    

    It is enough for files to have 644 and directories to have 755 permissions.

    If you're using a web hosting control panel the user could be different. You can use the posix_geteuid() function to find out the user ID of the current process.

    Thanked by 1myhken
  • Should it not be? Last time I used webmin(ages ago) it used to assign right perms. Then again things could always go wrong.

    @jarland said:

    myhken said: The ownership is the user of the site, so that's correct.

    Is it the user that PHP is executing the code as?

    Thanked by 1myhken
  • jarjar Patron Provider, Top Host, Veteran

    seriesn said: Should it not be?

    My time dealing with customers has taught me that a statement like this:

    myhken said: The ownership is the user of the site

    Could be taken to mean that "This is Bobby's site, so the user 'bobby' definitely owns the files." Meanwhile, it's not a suPHP environment and mod_php is executing the code as www-data.

    Thanked by 2myhken seriesn
  • @Jarland @jesin

    Let say that I have a user called Test that have a WordPress installation. Then under the file/folder rights it say test:test 0755 or test:test 0664
    And so on with all users on the server. So changing it to httpd:httpd will not help or?

  • jarjar Patron Provider, Top Host, Veteran
    edited September 2016

    myhken said: Let say that I have a user called Test that have a WordPress installation. Then under the file/folder rights it say test:test 0755 or test:test 0664 And so on with all users on the server. So changing it to httpd:httpd will not help or?

    Well unless you have something like a suPHP setup, the web server isn't executing the code as "test" but instead as "httpd" (assuming that's the correct user). If that's the case, httpd can't write to test's files by default. So you're having to change permissions to allow another user to write test's files. The correct short path would be to set the files to be owned by httpd then.

    Though you could do some stuff with groups I guess. There's no security gain there though IMO.

    Thanked by 1myhken
  • Going to setup a test domain and wordpress installation, and then see if I can change the settings to httpd:httpd. But that have to wait to tomorrow. Tnx for all inputs, and I will be back tomorrow asking more stupid questions ;)

  • myhken said: Let say that I have a user called Test that have a WordPress installation. Then under the file/folder rights it say test:test 0755 or test:test 0664 And so on with all users on the server. So changing it to httpd:httpd will not help or?

    Create an empty file inside the document root of the problematic WordPress with the following code:

    <?php echo exec('whoami'); ?>
    

    Access this file over the web browser. It'll display a username and all WordPress files should be owned by this user for updates to work.

    Thanked by 2jar myhken
  • @jesin

    Got apache, so then I have to change the settings to apache:apache then?

  • @jesin
    Yes, that worked. Changed user and group to apache on one site, and I could upgrade it without any issue. Sure auto update work later on also.
    And the site works fine with apache:apache

    So then I know what I will do tomorrow.... change all users and groups to apache.

    Thank you. And to all other helping me out.

    Thanked by 1jesin
  • myhken said: @jesin Yes, that worked. Changed user and group to apache on one site, and I could upgrade it without any issue. Sure auto update work later on also. And the site works fine with apache:apache

    So then I know what I will do tomorrow.... change all users and groups to apache.

    Great! Now put exec and similar functions in the disable_functions directive unless it is needed for something else :)

    Thanked by 1Falzo
  • instead of giving all files to apache hence making it possible to manipulate files cross-site in the worst case, it may be a better approach to switch to suphp, fastcgi/suexec, mpm_itk or likewise and keep the owners of the pages separated.

    as @jesin suggested keep a look at your php config and disable functions which may be considered a security risk. also have a look at directives like open_basedir which may add some isolation between your sites.

    Thanked by 2jar BeardyUnixGuy
  • myhkenmyhken Member
    edited September 2016

    What is the worst case scenario with using apache:apache on all sites @Falzo ? Sorry...you already told me...

  • Can I just change to suphp with the setup I have now? Will it work with Virtualmin, and my sites?

  • ManofServerManofServer Member
    edited September 2016

    I have a few Wordpress blogs for Linux ISO files, make sure you 755 all the domain folders and sub-folders (wp-content, wp-admin, etc.).

    Thanked by 1myhken
  • done

    Thanked by 1ManofServer
  • chown -R user.apache

    Should do what you want in most cases like this, if not then the above applies.

    Thanked by 1myhken
  • @ATHK said:
    chown -R user.apache

    Should do what you want in most cases like this, if not then the above applies.

    That did not work for updates of the sites. Working with apache:apache only.

  • @myhken said:

    @ATHK said:
    chown -R user.apache

    Should do what you want in most cases like this, if not then the above applies.

    That did not work for updates of the sites. Working with apache:apache only.

    Damn sorry for wasting your time! Stupid apache ;)

    Thanked by 1myhken
  • Don't worry. I open for all suggestions. But I think I have found the right path now. The only concern I have now it's security.
    I have of course blocked access to wp-admin. Just my IP's that has access. Also have changed SSH port, and use AllowUsers root@my IPs.

  • Changing ssh port won't do a thing a simple scanner can find and detect it.

    It may limit noise in the file though.

  • sle44102sle44102 Member
    edited September 2016

    Double check your settings in Virutalmin > Server Configuration > Website Options
    and be sure that PHP script execution mode is either FCGid or CGI Wrapper not apache mod_php.

    be sure to be logged in as the account you are trying to fix.

    I know i had that happen in the past on joomla sites where i fat fingered it and caused issues.

    Thanked by 1myhken
  • @ATHK said:
    Changing ssh port won't do a thing a simple scanner can find and detect it.

    It may limit noise in the file though.

    I know, but they can't login when they find it, if they don't have the correct IP, and then they have to use my computer.

  • @sle44102 said:
    Double check your settings in Virutalmin > Server Configuration > Website Options
    and be sure that PHP script execution mode is either FCGid or CGI Wrapper not apache mod_php.

    be sure to be logged in as the account you are trying to fix.

    I know i had that happen in the past on joomla sites where i fat fingered it and caused issues.

    All sites uses FCGid, so then all is OK?

  • @myhken: worst case scenarios are hard to grep, as there are a lot of possible configurations you could have set up :-)

    as for post above: if you have multiple websites running and all belong to apache, then if a single website got broken into the attacker may be able to gain access to the other sites too. just because he is able to run his scripts as apache user and possibly access all other files that belong that apache user on that server.

    limiting php access per vhost via a strict open_basedir rule may be one step to do against this, as there are other possibilities.

    if everything is already running via fcgi now you probably want to have a look into either suexec or mod_ruid2.

    if you like or need to run php as a apache module rather then via cgi wrapper I'd suggest mpm_itk which seems to deliver good performance while running childs with their respective owner.

    virtualmin might out of the box just use the default behaviour the system has been setup with, that may cause the differences in behaviour to your servers you used before.

    Thanked by 2myhken BeardyUnixGuy
  • @andygrider said:
    this is strange ı think , I dont change mods of the my files and everytime they are updated automatic .May be you should upload wordpress files manually .

    As I told in the first post, on some domains from one VPS it all worked fine. But on the rest, it did not work. But after advice in this thread, I have got it to work now.
    I'm not interested in updating lots of site manually. Before I had a script, uploaded the files to a folder, and updated all the sites on the VPS there it did not work with the script. Worked fine that also, but the best thing is autoupdate.

  • Just on a sidenote:
    I am always impressed how helpful and knowledgable most of @Falzo's posts here on LET are. We should really introduce something like a "Gold Member" or so tag for people as helpful as him. There is a good handful of members that I would have on my list and @Falzo is definitely one of them!

Sign In or Register to comment.