Make WordPress Core

Opened 18 years ago

Closed 17 years ago

Last modified 2 years ago

#3901 closed defect (bug) (wontfix)

Version Database updater displays to any user, not just administrators

Reported by: bradkovach's profile bradkovach 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)

#1 @JeremyVisser
18 years ago

  • Priority changed from normal to high
  • Severity changed from critical to normal

+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. ;)

#2 @markjaquith
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 @Nazgul
18 years ago

Can't we somehow leverage the wp-cron for this, because it already contains logic against contention (see [4509])

#4 @Nazgul
18 years ago

  • Keywords needs-patch added
  • Milestone changed from 2.3 (trunk) to 2.4 (future)

#5 @westi
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 @thee17
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.

#7 @thee17
17 years ago

  • Milestone 2.9 deleted

This ticket was mentioned in Slack in #core by boone. View the logs.


9 years ago

#9 @pento
9 years ago

#34200 was marked as a duplicate.

This ticket was mentioned in Slack in #core by swissspidy. View the logs.


8 years ago

#11 @jeremyfelt
5 years ago

#48895 was marked as a duplicate.

#12 @ocean90
5 years ago

#50274 was marked as a duplicate.

#13 @bartj
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.

Note: See TracTickets for help on using tickets.