Topic on Project:Support desk

I want to setup a MySQL user for MediaWiki (XAMPP on Windows). As there are other software running on the server, I would like to give each software its own MySQL user, so the software can only access its own MySQL tables.

My question is, which MySQL-rights does the MediaWiki software need, and which rights can (or should) I revoke?

Manual:MySQL did not offer any guidance. Tony Mach (talk) 09:55, 25 August 2014 (UTC)

I just saw, the installer has created a 'bn_mediawiki' MySQL user. However it has "ALL PRIVILEGES" on the bitnami_mediawiki table - is that OK? Tony Mach (talk) 10:28, 25 August 2014 (UTC)

Found this: Manual:Security#General_MySQL_recommendations

Quote: "The database user only needs to have SELECT, INSERT, UPDATE and DELETE permissions for the database."

I added a link at Manual:MySQL. Tony Mach (talk) 11:55, 25 August 2014 (UTC)

I don't think this list is complete. I currently do not know of a case where columns or tables have actually been removed, but that would require the DROP privilege. And during upgrade it will be necessary for the update.php script to create new columns and new tables. How should that work without ALTER table and CREATE table permissions?

You can set a DBadminuser (with more rights) for the maintance scripts:

• Manual:$wgDBadminuser
• Manual:$wgDBadminpassword

Don't know if that user will handle upgrade.

One more thing: On windows, the installer asks for the root password of the MySQL root account.

> Don't know if that user will handle upgrade.

Both variables will be used in the update script as well.

> On windows, the installer asks for the root password of the MySQL root account.

That's possible on Linux, too. But you can change the username (you should!), so it's only a suggestion :)

Yeah, I did that. I have now two users, I created one "everyday" user (with only the minimal rights), and one for admin tasks.

Furthermore, I move all account information out of LocalSettings.php, and into a "account file". (This was suggested somewhere on this wiki, forgot where). That "account file" resides *not* in the htdocs hierarchy, so it should not be accessable via http (in case something goes wrong with the apache settings).

Let's see how well this goes when we need to update ...