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?
Comments
I think you have to change the ownership of the files. Maybe someone can tell more on this.
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?
@WHT @seriesn
The ownership is the user of the site, so that's correct.
Just Akismet and Jetpack. And I use Virtualmin on CentOS 6.8 64bit
Yes
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:
On Apache (Debian variants):
Apache on CentOS:
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.Should it not be? Last time I used webmin(ages ago) it used to assign right perms. Then again things could always go wrong.
My time dealing with customers has taught me that a statement like this:
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.
@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?
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.
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
Create an empty file inside the document root of the problematic WordPress with the following code:
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.
@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.
Great! Now put
exec
and similar functions in thedisable_functions
directive unless it is needed for something elseinstead 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.
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?
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.).
done
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
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.
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.
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.
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.
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!