Opened 5 years ago
Last modified 5 months ago
#49440 new feature request
Allow configuring the upgrade directory
| Reported by: |
|
Owned by: | |
|---|---|---|---|
| Milestone: | Awaiting Review | Priority: | normal |
| Severity: | normal | Version: | |
| Component: | Upgrade/Install | Keywords: | |
| Focuses: | administration | Cc: |
Description
wp-content/upgrade is not application code, and it's not data. WordPress shouldn't hardcode where this directory is (especially to a location under the webroot).
Instead, the upgrade directory should be user-configurable & transient. This would allow things to continue as they are - but if someone wants to host their WordPress on a slow disk (HDD, NFS), they could.
The problem is when you have a slow disk, updates can fail because of HTTP timeouts. For example, an NFS volume containing a wordpress install is mounted in the webroot. Moving files across a network to unzip them is insane! It would make so much more sense to use a location like /tmp, which is already optimized for such a use case as unzipping files. Often, /tmp is a tempfs, which actually lives in memory.
Change History (8)
This ticket was mentioned in Slack in #core-auto-updates by pbiron. View the logs.
4 years ago
This ticket was mentioned in Slack in #hosting-community by pbiron. View the logs.
4 years ago
This ticket was mentioned in Slack in #hosting-community by crixu. View the logs.
4 years ago
This ticket was mentioned in Slack in #hosting-community by jadonn. View the logs.
4 years ago
#6
@
4 years ago
At WP Engine we lock down most of the filesystem outside of the webroot (though /tmp is available). This makes me worry a little bit about the customer experience of sites migrating onto our platform that have settings/code to override this directory to a path that's not usable on our system. For this not to cause breakage, we would have to override that setting with a value that works on our platform. This isn't a problem per se, but having some lead time what filter needs to be put in place ahead of a rollout so that we can pre-deploy such a filter in an mu-plugin would be appreciated and reduce customer pain.
Also, the security implications of allowing writes to /tmp for this purpose are interesting from the perspective of shared hosting. If the subpaths under /tmp are fixed/guessable, then this opens the possibility of two tenants attempting to write in the same location concurrently. This could cause undefined behavior in the innocent case or open up a vector for malicious actors to inject malicious code into updates, resulting in that code being injected into all tenants using the same path. Again, not a problem if hosting companies pre-deploy filters for customer-specific paths with sufficient entropy, but common default implementations could leave sites vulnerable.
Related: #50797