WordPress.org

Make WordPress Core

Opened 4 years ago

Last modified 21 months ago

#11717 new enhancement

Access to automatic database repair/optimize with admin rights

Reported by: neoxx Owned by: ryan
Milestone: Future Release Priority: normal
Severity: normal Version: 2.9.1
Component: Database Keywords: has-patch 2nd-opinion
Focuses: Cc:

Description

Hi,

I read somewhere that the reason for using a constant as enabler for the automatic repairing/optimizing database functionality was, that some people are not able to access their back-end in case certain tables are broken.

Anyway, as db optimization (and not only repairing) is also included in /wp-admin/maint/repair.php, it would be helpful, if we could avoid setting the constant and in addition grant users with the admin role the right to access the functionality.

I've added the necessary two lines and attached a patch to this ticket. - Hopefully this will make it into core, because it would really ease access and increase usability.

My Best,
Berny

Attachments (1)

11717.diff (1.6 KB) - added by neoxx 4 years ago.

Download all attachments as: .zip

Change History (11)

comment:1 dd324 years ago

Is get_currentuserinfo(); even required?

comment:2 neoxx4 years ago

@dd32: Thanks for your hint! - You're right: current_user_can() calls wp_get_current_user() which calls get_currentuserinfo(); - I've updated the patch.

In addition a capability like repair_tables would round this patch up. And maybe we should think about the extension towards a canonical plugin...

neoxx4 years ago

comment:3 dd324 years ago

Another thing that should be noted... Will a crashed Users table or options table, with this change, prevent access to the error message?

Part of the reason this is in core, is to allow everyone to have access to it when their database crashes, as a plugin, it may not be activated. As a plugin, If the options table crashes, it will not be loaded.

comment:4 neoxx4 years ago

I agree, though I meant that we could use the same functionality (derived from the same include-file) within the back-end (especially for the optimization) and as a stand-alone file. That way we could increase the usability for (scheduled) maintenance whilst still providing access in case of emergency-repairs.

Moreover, I don't think that a crashed users table will return a working user's object which holds an admin status, but this would definitely be an interesting attacking scenario. ;)

Greetz to Kyogle,
Berny

comment:5 follow-up: dd324 years ago

Moreover, I don't think that a crashed users table will return a working user's object which holds an admin status, but this would definitely be an interesting attacking scenario. ;)

I was thinking of:

  • users table crashes
  • User visits repair page
  • User doesnt have constant defined
  • File then checks for current_user_can()
    • Database error occurs
  • ???
    • Database error message is shown and thats that? - Ie. no "Please define this constant. blahblah"
    • current_user_can returns false and the "please define this constant blahblah" IS shown.

Not too sure how to simulate a crashed table myself..

comment:6 in reply to: ↑ 5 hakre4 years ago

Replying to dd32:

Not too sure how to simulate a crashed table myself..

I think mysql stores it's data on disk. How about smashing the file related to the database? echoing random data into it or just deleting it maybe does already the job.

comment:7 dd324 years ago

How about smashing the file related to the database?

That'll corrupt the entire database, Not crash a table AFAIK

comment:8 mrmist4 years ago

It's difficult to corrupt a table with any particular degree of precision as the database systems are pretty much designed to prevent such things.

Some folk suggest hex editing of a few values in the database files, but even that is unpredictable at best.

Your best actions for testing would probably just be to force the PHP code down the repair route.

comment:9 nacin4 years ago

  • Milestone changed from 3.0 to Future Release

comment:10 nacin21 months ago

  • Keywords 2nd-opinion added; repair db removed

Seems somewhat okay to me to allow repair if is_super_admin(). Obviously, that check will fail if the database is unavailable. But if enough tables are available (users, usermeta, and potentially options), then it's a nice little enhancement, particularly to allow for optimizes without the need to trigger a repair.

That said, we should allow WP_ALLOW_REPAIR to be false and prevent the script from running in this case.

I'm also okay with denying this implicit cap check (thus requiring WP_ALLOW_REPAIR) if DO_NOT_UPGRADE_GLOBAL_TABLES is set. Also potentially multisite in general.

Eh. I'm kind of okay with a wontfix, rather than conflating DB admin and site admin roles unreasonably.

Note: See TracTickets for help on using tickets.