-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
Warn about "Any user" potential problem #6300
Description
I realized today why I have spent hours of my life debugging the same error:
mysql -u cohtaxion -p test
ERROR 1045 (28000): Accès refus' pour l'utilisateur: 'cohtaxion'@'@localhost' (m
ot de passe: OUI)
In English : Access refused for user: [...](password: YES)
https://dev.mysql.com/doc/refman/5.6/en/problems-connecting.html explains:
If you cannot figure out why you get Access denied, remove from the user table all rows that have Host values containing wildcards (rows that contain '%' or '_' characters). A very common error is to insert a new row with Host='%' and User='some_user', thinking that this enables you to specify localhost to connect from the same machine. The reason that this does not work is that the default privileges include a row with Host='localhost' and User=''. Because that row has a Host value 'localhost' that is more specific than '%', it is used in preference to the new row when connecting from localhost! The correct procedure is to insert a second row with Host='localhost' and User='some_user', or to delete the row with Host='localhost' and User=''. After deleting the row, remember to issue a FLUSH PRIVILEGES statement to reload the grant tables. See also Section 6.2.4, “Access Control, Stage 1: Connection Verification”.
In other words, for MySQL "users" are different from identities. Since many (most?) MySQL installs will come by default with low-privileged (USAGE) identities on Host %, trying to create user foo for Host % will make foo unable to connect. In other words, if you choose Host so that you get the least connection problems, you trigger a connection problem.
This is obviously a major usability bug in MySQL, but it doesn't mean phpMyAdmin can't help. In fact, looking at the Users tab, the identities listed are presented as users. The page is titled "Users overview", and at the bottom, the user is offered to "Add user", or to "Remove selected users". This is standard terminology, but prevents users from realizing that a user is not what they think it is for MySQL.
It may not be needed to change terminology everywhere, but I would recommend:
To change "Users overview" to "Identities overview".
s/Add user/Add identity/
s/Remove selected users/Remove selected identities/
Possibly rename the tab from "Users" to "Identities", but that is slightly longer.
This issue was previously reported in http://sourceforge.net/p/phpmyadmin/bugs/4273/
Marc Delisle indicated there that phpMyAdmin warns about this problem since version 4.1. I did notice this warning in my phpMyAdmin 4.1.14. I am not saying there was none though - it's a fresh install, and there were other warnings which I was ignoring. I am sure, however, that I was never asked to confirm when I added the user. Ideally, phpMyAdmin would detect if there is a possible overlap between identities and require a confirmation in such cases.
Just to clarify - the reason why this bug has cost me hours is that I am not a system administrator. Months go between every time I hit this issue, and I have forgotten the next time. I suspect this is not a unique case for phpMyAdmin users.
- Original URL: https://sourceforge.net/p/phpmyadmin/feature-requests/1686/
- Original author: chealer