#3901 closed defect (bug) (wontfix)
Version Database updater displays to any user, not just administrators
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | high | |
Severity: | normal | Version: | 2.1.1 |
Component: | Administration | Keywords: | needs-patch |
Focuses: | Cc: |
Description
When an upgrade to WordPress has been performed, and wp-admin/ is visited, any visitor, not just logged in users, can initiate the update process. Simultaneous upgrades could cause problems.
Change History (13)
#2
@
18 years ago
Asking for a login won't guarantee non-simultaneous upgrades. We'd need some sort of mutex scheme.
Seems an edge case, though... there's a limited window for simultaneous upgrades, and most upgrade functions should be safe to run more than once. If they aren't, they should be rewritten.
#3
@
18 years ago
Can't we somehow leverage the wp-cron for this, because it already contains logic against contention (see [4509])
#5
@
17 years ago
- Milestone changed from 2.5 to 2.6
This needs serious thought before changing - if we want to avoid the concurrency then we need to have a mutex of some sort and lots of testing.
Moving out of this release.
#6
@
17 years ago
- Resolution set to wontfix
- Status changed from new to closed
This appears to have lost traction. And appears to be a mute point.
This ticket was mentioned in Slack in #core by boone. View the logs.
9 years ago
This ticket was mentioned in Slack in #core by swissspidy. View the logs.
8 years ago
#13
@
2 years ago
As similar tickets are marked as duplicate, I'd decided to post my comment with ask to reconsider the issue here, but on different basis than argued in this ticket.
I don't think it's essentially a potentially simultaneous upgrade problem, but rather something what may be perceived as vulnerability, especially when reckoning WordPress as a secure and user-friendly platform.
The reasoning behind hiding this screen from regular visitors should be to never allow any unauthenticated action when considering administrative tasks. As a website owner, I rightfully might demand to have control over my environment and database update should be considered as one of such (sensitive) tasks.
Even though unauthenticated execution wouldn't bring any malicious effects, and it's rather unlikely that simultaneous upgrades would break a website, the very thought that any unknown actor could do something on my website is a quite thrilling perspective.
Previously (https://core.trac.wordpress.org/ticket/34200#comment:7), it's been argued that upgrade screen may be curl
'ed, thus authentication could introduce unnecessary burden, but such reasoning is deniable. Having at least *Basic* authentication header sent would easily adopt a more secure (at least perceived as secure) solution.
Although not entirely in line with my beliefs about the case, I think @bamadesigner's comment from another ticket (https://core.trac.wordpress.org/ticket/34200#comment:12) grasps the very root issue of deciding against not-hiding/having at all the upgrade screen.
+1. I have worried about this in the past, as well. Simple solution is to ask the user to log in first.
In fact, occasionally when I have come across someone's blog and I see some database errors being ejected into the sidebar, etc., I have gone into /wp-admin/ just to check to see if there's an update pending, and done it for them.
;)