Impossible de diagnostiquer mon problème d'utilisateur root MySQL

Question

J'ai un problème avec l'utilisateur root MySQL dans l'installation de MySQL, et je ne peux tout simplement pas trouver de solution pour résoudre ce problème. Il semble que j'ai quelque peu raté l'utilisateur root, et mon accès aux bases de données est maintenant très erratique. Pour référence, j'utilise MAMP sur OS X pour fournir le serveur MySQL. Je ne suis pas sûr de savoir à quel point cela compte - je suppose que tout ce que j'ai fait nécessitera une correction en ligne de commande pour le résoudre.

Je peux démarrer MySQL en utilisant MAMP comme d'habitude, et accéder aux bases de données en utilisant les utilisateurs 'standards' que j'ai créés pour mes applications PHP. Cependant, l'utilisateur root, que j'utilise dans mon client MySQL GUI, et aussi dans phpMyAdmin, ne peut accéder qu'à la base de données "information_schema", ainsi qu'à deux que j'ai créées manuellement, et vraisemblablement (et par erreur) laissées largement ouvertes. Mes 15 autres bases de données ne sont pas accessibles à mon utilisateur root. Lorsque je charge phpMyAdmin, l'écran d'accueil indique: "Créer une nouvelle base de données: aucun privilège".

J'ai certainement modifié le mot de passe de mon utilisateur root en utilisant le dialogue MAMP. Mais je ne me souviens pas si j'ai fait quoi que ce soit d'autre qui aurait pu causer ce problème. J'ai essayé de changer le mot de passe encore, et il semble y avoir aucun changement dans le problème.

J'ai également essayé de réinitialiser le mot de passe root en utilisant la ligne de commande, y compris démarrer mysql manuellement avec --skip-grant-tables puis vider les privs, mais encore une fois, rien ne semble résoudre le problème.

Je suis arrivé à la fin de mes idées, et j'apprécierais beaucoup des conseils et des diagnostics étape par étape d'un des experts ici!

Un grand merci pour votre aide.

Answer 1

C'est parce que MAMP et la commande La ligne mysql (et le mysql tout sauf MAMP) sont différentes. MAMP a son propre mysql intégré et vous ne pouvez pas y accéder via la ligne de commande, seulement la construction de phpmyadmin.

cela a été mon expérience, j'ai MAMP et utiliser l'autre mysql pour ruby ​​sur rails et autres choses.

Answer 2

Essayez de démarrer le serveur avec --skip-grant-tables, puis vérifier les tables de privilège dans la base de données MySQL:

select * from user where User='root'; 
select * from tables_priv where User='root'; 
select * from db where User='root'; 

Vous pouvez également essayer:

show grants for root@localhost; 
show grants for root@'%'; 
show grants for root@'hostname'; 

Une fois en vous pourriez faites ceci pour essayer de donner des privilèges complets à la racine:

grant all privileges on *.* to root@localhost identified by 'password' with grant option; 

Answer 3

Votre commentaire indique vos privilèges root actuels (sans --skip-grant-tables). C'est bien que vous n'avez aucune entrée pour 'root' @ '%', vous ne l'avez pas par défaut et vous pouvez le considérer comme une mesure de sécurité.

Il semble que vous ayez raté vos privilèges 'root'@'localhost'. GRANT ALL PRIVILEGES ON . est bizarre. Habituellement, vous avez quelque chose comme GRANT ALL PRIVILEGES ON *.* ou GRANT ALL PRIVILEGES ON myDatabase.myTable. Votre GRANT ne spécifie pas les bases de données et/ou les tables pour lesquelles accorder les privilèges. Je n'ai aucune idée de comment votre client a réussi à le produire. Je ne peux pas le reproduire avec le client de ligne de commande mysql (essayé des chaînes vides, des espaces, n'importe quel type de guillemets ...), mysql refuse l'instruction GRANT (ce qui, bien sûr, est le comportement correct). On dirait que MAMP fait quelque chose de vraiment étrange.Comme je ne peux pas reproduire un GRANT comme le vôtre, je ne peux pas dire comment mysql l'interprète, mais je suppose qu'il a défini les privilèges sur 'N' au niveau global.

Pour le réparer, vous avez besoin d'un utilisateur avec des privilèges appropriés. Habituellement, vous avez un utilisateur 'root'@'localhost' et un 'root'@'your-hostname'. Si vous êtes chanceux, 'root'@'your-hostname' est toujours bien. Afair, connexions mysql fonctionnent comme suit: Si vous vous connectez à localhost, vous vous connectez comme 'root'@'localhost' (pas sûr de 127.0.0.1, je suppose que c'est aussi 'root'@'localhost'). Si vous vous connectez à your-hostname, vous vous connectez en tant que 'root'@'your-hostname'. Si les privilèges de cet utilisateur sont toujours corrects, vous pouvez mettre à jour les privilèges pour 'root'@'localhost' et vous avez terminé.

Dans votre commentaire, vous dites que vous ne pouvez pas vous connecter via 127.0.0.1 car le socket est dans un endroit inhabituel. Je suppose que vous interprétez mal l'erreur. IIRC vous vous connectez via socket si vous vous connectez à 'localhost', mais via TCP/IP si vous vous connectez à 127.0.0.1 ou your-hostname. Si mysql essaie de se connecter via socket et ne trouve pas le socket (parce que vous n'avez pas spécifié l'emplacement correct), le message d'erreur mentionne où mysql a essayé de trouver le socket. Votre message d'erreur ne le fait pas. Je suppose que votre erreur est une erreur de réseau. Vous avez peut-être démarré le serveur mysql avec l'option --skip-networking, ou votre configuration spécifie une adresse de liaison incorrecte. Vous devez d'abord résoudre ce problème, sinon vous ne pouvez pas vous connecter en tant que 'root'@'your-hostname'.

Answer 4

J'ai eu le même problème: un seul compte d'utilisateur a travaillé pour accéder aux bases de données mysql via la console d'administration ou le navigateur de requêtes. Lorsque j'ai utilisé les tables skip-grant, tous les comptes pouvaient se connecter, y compris root.

Je l'ai vu as a bug as far back as 2006, mais l'entrée finale là n'est pas une commande qui peut être exécutée en mode skip-grant-tables, donc je n'ai toujours pas résolu le problème.

Ce qui m'a aidé
Cette réponse est similaire à celle décrite par Ben Bakelaar in the above link. Le problème vient lorsque votre my.ini a l'indicateur de résolution de nom désactivé (skip-name-resolve). Cela tue la capacité de mysql à résoudre 'localhost' et la table mysql.user n'a qu'une entrée pour localhost/root.

Mettez à jour l'entrée localhost de votre table mysql.user à la place de 127.0.0.1 et vous pouvez vous connecter aux consoles locales même si la fonction skip-name-resolve est activée.