Last modified: 2011-03-01 18:46:40 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 12070 - After Installation MySQL was blocked
After Installation MySQL was blocked
Product: MediaWiki
Classification: Unclassified
Installer (Other open bugs)
All All
: Normal major (vote)
: ---
Assigned To: Chad H.
: patch, patch-need-review
Depends on:
Blocks: 26676
  Show dependency treegraph
Reported: 2007-11-23 06:44 UTC by Grotenhermen
Modified: 2011-03-01 18:46 UTC (History)
6 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---

Fix for password overwrite in GRANT (4.00 KB, patch)
2011-02-24 21:33 UTC, Chad H.
Try #2 (4.49 KB, patch)
2011-02-28 19:07 UTC, Chad H.

Description Grotenhermen 2007-11-23 06:44:28 UTC
After Installtaion of mediawiki-1.11.0.tar.gz on my PC (XAMP) had no access to MySQL was possible. I have deleted Wiki and XAMP reinstalled.
Comment 1 Robert Leverington 2007-11-23 16:01:11 UTC
There is no way that MediaWiki could break your MySQL, due to the nature of installing MediaWiki on your home computer (which I am presuming you did) it is quite possible that in the process of preparing your environment to install MediaWiki you broke something, or tinckering afterwards caused something bad to ocurr. Regardless, it is not MediaWiki.
Comment 2 Tim Starling 2007-11-23 16:31:47 UTC
MediaWiki can create a MySQL user with a different hostname to a pre-existing user, and thereby potentially override the pre-existing user's grants, if the new user is earlier in the hostname search order. The new user may then have a different set of privileges and a different password. I saw a report of this on #mediawiki two days ago -- someone claimed that all the databases except MediaWiki's were dropped by the MediaWiki installer, and that existing web applications stopped working. The problem was the lack of global usage rights for the new user.

It would be nice to have some feedback from the reporter as to whether this was possibly the case here, since it is a real problem with the MediaWiki installer and needs to be fixed.
Comment 3 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-12-18 18:00:45 UTC
Not a blocker, does not block development.  Assuming some easy workaround exists, so this isn't critical, no worse than major.
Comment 4 Grotenhermen 2007-12-19 08:16:38 UTC
After installation Wiki has creade a password for my MySQL on my PC.
I can't log in and must look in the config to finde this password.
I look in my at phpMyAdmin and found the password :-))

But why Wiki don't tell me this during the installation?

Comment 5 Tim Starling 2009-01-09 05:23:04 UTC
I've discovered that the MediaWiki installer is capable of silently changing the password of an existing user account. This will be fixed in the new installer, targeted for 1.15. 
Comment 6 Chad H. 2010-09-09 21:57:22 UTC
Pinging this. New installer is now targeted for 1.17.
Comment 7 Max Semenik 2011-02-20 17:12:30 UTC
This bug is still present in new installer marking as a blocker for 1.17. 

* Create user foo with some password
* Run the installer
* On page=DBSettings, uncheck "Use the same account as for installation"
* Enter foo as username
* Enter a DIFFERENT password for this user
* Check "Create the account if it does not already exist"
* Finish installation

foo's password will be changed.
Comment 8 Platonides 2011-02-21 23:18:36 UTC
User creation is done inside maintenance/users.sql using GRANT ALL PRIVILEGES ON 
$db TO $wgDBuser IDENTIFIED BY $pass;
> When the IDENTIFIED BY clause is present and you have global grant privileges, 
> the password becomes the new password for the account, even if the account 
> exists and already has a password. With no IDENTIFIED BY clause, the account 
> password remains unchanged. 

It should instead use CREATE USER where "An error occurs if the account already exists".

If the CREATE USER for any of the three accounts already exist, it should abort.

It could still mask a user with the same name but different host, but manually performing queries to mysql.user doesn't look nice (we should at least skip any error on doing so).
Comment 9 Chad H. 2011-02-24 21:33:27 UTC
Created attachment 8209 [details]
Fix for password overwrite in GRANT

Separates the CREATE and GRANT stages so we can handle them separately (and not overwrite the password silently).

Attempts to check mysql.user if we can, but creates anyway if we can't verify.
Comment 10 Platonides 2011-02-24 23:09:24 UTC
I would perform the grant directly from there, too. users.sql duplicates information that is now copied into MysqlInstaller.php so I would get rid of the sql file.
If the mysql.user found it existed or the create user failed with whatever error code there is for already exist, it should show "User $1 already exists" (informative), not 'Creating user "$1" failed: $2'.

Wrap everything in a transaction.
Comment 11 Chad H. 2011-02-28 19:07:33 UTC
Created attachment 8223 [details]
Try #2

Applies changes from previous comment.
Comment 12 Platonides 2011-02-28 23:08:24 UTC
Looks good. What should we do when there is just one of the accounts? Should we proceed to create the other two?
Comment 13 Chad H. 2011-03-01 14:43:00 UTC
I figured just to continue and try to make all 3, but it can go either way.
Comment 14 Chad H. 2011-03-01 18:46:40 UTC
Fixed in r83029.

Note You need to log in before you can comment on or make changes to this bug.