Mixing
WordPress - Hardened permissions with automatic updates?
Is there a way to allow WordPress to automatically update while still using hardened permissions?
It seems the recommended security setup for WordPress is to use hardened permissions, which are mostly achieved using the permissions given in this answer. However, these permissions result in WordPress not being able to automatically update, or use update through the administrator web interface, resulting in an error:
Downloading update from https://downloads.wordpress.org/release/wordpress-x.x.x-partial-x.zip…
Unpacking the update…
The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php
Installation Failed
By allowing the web server to update update-core.php we violate the hardened permissions (as far as I can tell). Unfortunately, without automatic updates, we also have the problem that we don't get automatic security updates, which leads to another security problem. Is there a way to allow automatic updates without the need for weak permissions? What are the strongest permissions that can be used while still allowing automatic updates, and is that strong enough?
wordpress permissions
asked Nov 21 '18 at 15:32
Jenny ShoarsJenny Shoars
471528
add a comment |
Is there a way to allow WordPress to automatically update while still using hardened permissions?
It seems the recommended security setup for WordPress is to use hardened permissions, which are mostly achieved using the permissions given in this answer. However, these permissions result in WordPress not being able to automatically update, or use update through the administrator web interface, resulting in an error:
Downloading update from https://downloads.wordpress.org/release/wordpress-x.x.x-partial-x.zip…
Unpacking the update…
The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php
Installation Failed
By allowing the web server to update update-core.php we violate the hardened permissions (as far as I can tell). Unfortunately, without automatic updates, we also have the problem that we don't get automatic security updates, which leads to another security problem. Is there a way to allow automatic updates without the need for weak permissions? What are the strongest permissions that can be used while still allowing automatic updates, and is that strong enough?
wordpress permissions
asked Nov 21 '18 at 15:32
Jenny ShoarsJenny Shoars
471528
add a comment |
Is there a way to allow WordPress to automatically update while still using hardened permissions?
It seems the recommended security setup for WordPress is to use hardened permissions, which are mostly achieved using the permissions given in this answer. However, these permissions result in WordPress not being able to automatically update, or use update through the administrator web interface, resulting in an error:
Downloading update from https://downloads.wordpress.org/release/wordpress-x.x.x-partial-x.zip…
Unpacking the update…
The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php
Installation Failed
By allowing the web server to update update-core.php we violate the hardened permissions (as far as I can tell). Unfortunately, without automatic updates, we also have the problem that we don't get automatic security updates, which leads to another security problem. Is there a way to allow automatic updates without the need for weak permissions? What are the strongest permissions that can be used while still allowing automatic updates, and is that strong enough?
wordpress permissions
asked Nov 21 '18 at 15:32
Jenny ShoarsJenny Shoars
471528
Is there a way to allow WordPress to automatically update while still using hardened permissions?
It seems the recommended security setup for WordPress is to use hardened permissions, which are mostly achieved using the permissions given in this answer. However, these permissions result in WordPress not being able to automatically update, or use update through the administrator web interface, resulting in an error:
Downloading update from https://downloads.wordpress.org/release/wordpress-x.x.x-partial-x.zip…
Unpacking the update…
The update cannot be installed because we will be unable to copy some files. This is usually due to inconsistent file permissions.: wp-admin/includes/update-core.php
Installation Failed
By allowing the web server to update update-core.php we violate the hardened permissions (as far as I can tell). Unfortunately, without automatic updates, we also have the problem that we don't get automatic security updates, which leads to another security problem. Is there a way to allow automatic updates without the need for weak permissions? What are the strongest permissions that can be used while still allowing automatic updates, and is that strong enough?
wordpress permissions
wordpress permissions
asked Nov 21 '18 at 15:32
Jenny ShoarsJenny Shoars
471528
asked Nov 21 '18 at 15:32
Jenny ShoarsJenny Shoars
471528
asked Nov 21 '18 at 15:32
Jenny ShoarsJenny Shoars
471528
asked Nov 21 '18 at 15:32
Jenny ShoarsJenny Shoars
471528
asked Nov 21 '18 at 15:32
Jenny ShoarsJenny Shoars
471528
471528
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
The Hardening Wordpress guide describes on what's a secure setup and recommends automatic updates, but conveniently omits that the former doesn't work with them.
To my knowledge, every admin just has a very unpleasant choice to make:
- Keep the hardened permissions, requiring keeping on top of every single minor update and changing permissions back and forth to execute it
- Loosen permissions in a non-documented way and risk the associated increased insecurities
As somebody who primarily deals with automation, personally I just can't get behind the manual approach. It seems like less of a risk, but that's only if you never happen to let an update go unattended for a week or two. Then arguably the risk is higher due to the unpatched vulnerabilities than it would have been for the looser permissions.
Here's the extract that I use to switch to "insecure" mode for the few seconds it takes to update (and that I'll be using until something better comes along or my patience with this manual approach ends):
sudo chown -R <wordpress_user> <wp_rootdir>; read; sudo chown -R <myuser> <wp_rootdir>
It changes the owner of everything to the process that runs WordPress and uses the "read" command just to hold up until you press any button to then restore back to the original owner.
TL;DL: No, there is only the choice of two extremities.
answered Jan 15 at 14:53
insideClawinsideClaw
436
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53415449%2fwordpress-hardened-permissions-with-automatic-updates%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
The Hardening Wordpress guide describes on what's a secure setup and recommends automatic updates, but conveniently omits that the former doesn't work with them.
To my knowledge, every admin just has a very unpleasant choice to make:
- Keep the hardened permissions, requiring keeping on top of every single minor update and changing permissions back and forth to execute it
- Loosen permissions in a non-documented way and risk the associated increased insecurities
As somebody who primarily deals with automation, personally I just can't get behind the manual approach. It seems like less of a risk, but that's only if you never happen to let an update go unattended for a week or two. Then arguably the risk is higher due to the unpatched vulnerabilities than it would have been for the looser permissions.
Here's the extract that I use to switch to "insecure" mode for the few seconds it takes to update (and that I'll be using until something better comes along or my patience with this manual approach ends):
sudo chown -R <wordpress_user> <wp_rootdir>; read; sudo chown -R <myuser> <wp_rootdir>
It changes the owner of everything to the process that runs WordPress and uses the "read" command just to hold up until you press any button to then restore back to the original owner.
TL;DL: No, there is only the choice of two extremities.
answered Jan 15 at 14:53
insideClawinsideClaw
436
add a comment |
The Hardening Wordpress guide describes on what's a secure setup and recommends automatic updates, but conveniently omits that the former doesn't work with them.
To my knowledge, every admin just has a very unpleasant choice to make:
- Keep the hardened permissions, requiring keeping on top of every single minor update and changing permissions back and forth to execute it
- Loosen permissions in a non-documented way and risk the associated increased insecurities
As somebody who primarily deals with automation, personally I just can't get behind the manual approach. It seems like less of a risk, but that's only if you never happen to let an update go unattended for a week or two. Then arguably the risk is higher due to the unpatched vulnerabilities than it would have been for the looser permissions.
Here's the extract that I use to switch to "insecure" mode for the few seconds it takes to update (and that I'll be using until something better comes along or my patience with this manual approach ends):
sudo chown -R <wordpress_user> <wp_rootdir>; read; sudo chown -R <myuser> <wp_rootdir>
It changes the owner of everything to the process that runs WordPress and uses the "read" command just to hold up until you press any button to then restore back to the original owner.
TL;DL: No, there is only the choice of two extremities.
answered Jan 15 at 14:53
insideClawinsideClaw
436
add a comment |
The Hardening Wordpress guide describes on what's a secure setup and recommends automatic updates, but conveniently omits that the former doesn't work with them.
To my knowledge, every admin just has a very unpleasant choice to make:
- Keep the hardened permissions, requiring keeping on top of every single minor update and changing permissions back and forth to execute it
- Loosen permissions in a non-documented way and risk the associated increased insecurities
As somebody who primarily deals with automation, personally I just can't get behind the manual approach. It seems like less of a risk, but that's only if you never happen to let an update go unattended for a week or two. Then arguably the risk is higher due to the unpatched vulnerabilities than it would have been for the looser permissions.
Here's the extract that I use to switch to "insecure" mode for the few seconds it takes to update (and that I'll be using until something better comes along or my patience with this manual approach ends):
sudo chown -R <wordpress_user> <wp_rootdir>; read; sudo chown -R <myuser> <wp_rootdir>
It changes the owner of everything to the process that runs WordPress and uses the "read" command just to hold up until you press any button to then restore back to the original owner.
TL;DL: No, there is only the choice of two extremities.
answered Jan 15 at 14:53
insideClawinsideClaw
436
The Hardening Wordpress guide describes on what's a secure setup and recommends automatic updates, but conveniently omits that the former doesn't work with them.
To my knowledge, every admin just has a very unpleasant choice to make:
- Keep the hardened permissions, requiring keeping on top of every single minor update and changing permissions back and forth to execute it
- Loosen permissions in a non-documented way and risk the associated increased insecurities
As somebody who primarily deals with automation, personally I just can't get behind the manual approach. It seems like less of a risk, but that's only if you never happen to let an update go unattended for a week or two. Then arguably the risk is higher due to the unpatched vulnerabilities than it would have been for the looser permissions.
Here's the extract that I use to switch to "insecure" mode for the few seconds it takes to update (and that I'll be using until something better comes along or my patience with this manual approach ends):
sudo chown -R <wordpress_user> <wp_rootdir>; read; sudo chown -R <myuser> <wp_rootdir>
It changes the owner of everything to the process that runs WordPress and uses the "read" command just to hold up until you press any button to then restore back to the original owner.
TL;DL: No, there is only the choice of two extremities.
answered Jan 15 at 14:53
insideClawinsideClaw
436
answered Jan 15 at 14:53
insideClawinsideClaw
436
answered Jan 15 at 14:53
insideClawinsideClaw
436
answered Jan 15 at 14:53
insideClawinsideClaw
436
436
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53415449%2fwordpress-hardened-permissions-with-automatic-updates%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
