Accès refusé à l’utilisateur ‘root’ @ ‘localhost’ lors de la tentative d’octroi de privilèges. Comment accorder des privilèges?

J’ai examiné un certain nombre de questions similaires et je démontre que j’ai vérifié les bases. Bien sûr, cela ne signifie pas que je n’ai rien manqué de évident. 🙂

Ma question est la suivante: pourquoi n’ai-je pas access à un utilisateur ayant le privilège de faire ce que j’essaie de faire et où j’ai déjà saisi le mot de passe et obtenu l’access? (Par souci d’exhaustivité, j’ai essayé de taper le mauvais mot de passe pour m’assurer que le client MySQL me refuserait l’access au démarrage du programme.)

Contexte:

Connecté au shell de la machine exécutant le serveur MySQL via ssh, je me connecte en tant que root:

[myname@host ~]$ mysql -u root -p -hlocalhost Enter password: Welcome to the MySQL monitor. Commands end with ; or \g. Your MySQL connection id is 62396 Server version: 5.5.18-log MySQL Community Server (GPL) Type 'help;' or '\h' for help. Type '\c' to clear the current input statement. mysql> 

Impressionnant. Ma lecture des réponses à des questions similaires suggère que je devrais m’assurer que les privilèges sont à jour avec ce qui est dans les tables de subvention

 mysql> FLUSH PRIVILEGES; Query OK, 0 rows affected (0.00 sec) mysql> 

Assurez-vous ensuite que je suis qui je pense être:

 mysql> SELECT user(); +----------------+ | user() | +----------------+ | root@localhost | +----------------+ 1 row in set (0.00 sec) 

… et assurez-vous vraiment:

 mysql> SELECT current_user(); +----------------+ | current_user() | +----------------+ | root@localhost | +----------------+ 1 row in set (0.00 sec) mysql> 

Jusqu’ici tout va bien. Maintenant quels privilèges ai-je?

 mysql> SHOW GRANTS FOR 'root'@'localhost'; +----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | Grants for root@localhost | +----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ | GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, RELOAD, SHUTDOWN, PROCESS, FILE, REFERENCES, INDEX, ALTER, SHOW DATABASES, SUPER, CREATE TEMPORARY TABLES, LOCK TABLES, EXECUTE, REPLICATION SLAVE, REPLICATION CLIENT, CREATE VIEW, SHOW VIEW, CREATE ROUTINE, ALTER ROUTINE, CREATE USER, EVENT, TRIGGER ON *.* TO 'root'@'localhost' IDENTIFIED BY PASSWORD '[OBSCURED]' WITH GRANT OPTION | +----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ 1 row in set (0.00 sec) 

Maintenant que c’est un peu difficile à lire, essayons de cette façon (vous verrez également qu’il y a un utilisateur ‘root’ non-localhost):

 mysql> SELECT * FROM mysql.user WHERE User='root'\G *************************** 1. row *************************** Host: localhost User: root Password: *[OBSCURED] Select_priv: Y Insert_priv: Y Update_priv: Y Delete_priv: Y Create_priv: Y Drop_priv: Y Reload_priv: Y Shutdown_priv: Y Process_priv: Y File_priv: Y Grant_priv: Y References_priv: Y Index_priv: Y Alter_priv: Y Show_db_priv: Y Super_priv: Y Create_tmp_table_priv: Y Lock_tables_priv: Y Execute_priv: Y Repl_slave_priv: Y Repl_client_priv: Y Create_view_priv: Y Show_view_priv: Y Create_routine_priv: Y Alter_routine_priv: Y Create_user_priv: Y Event_priv: Y Trigger_priv: Y ssl_type: ssl_cipher: x509_issuer: x509_subject: max_questions: 0 max_updates: 0 max_connections: 0 max_user_connections: 0 *************************** 2. row *************************** Host: [HOSTNAME].com User: root Password: *[OBSCURED] Select_priv: Y Insert_priv: Y Update_priv: Y Delete_priv: Y Create_priv: Y Drop_priv: Y Reload_priv: Y Shutdown_priv: Y Process_priv: Y File_priv: Y Grant_priv: Y References_priv: Y Index_priv: Y Alter_priv: Y Show_db_priv: Y Super_priv: Y Create_tmp_table_priv: Y Lock_tables_priv: Y Execute_priv: Y Repl_slave_priv: Y Repl_client_priv: Y Create_view_priv: Y Show_view_priv: Y Create_routine_priv: Y Alter_routine_priv: Y Create_user_priv: Y Event_priv: Y Trigger_priv: Y ssl_type: ssl_cipher: x509_issuer: x509_subject: max_questions: 0 max_updates: 0 max_connections: 0 max_user_connections: 0 2 rows in set (0.00 sec) 

Impressionnant! MySQL pense que je suis root @ localhost et que root @ localhost a tous ces privilèges. Cela signifie que je devrais pouvoir faire ce que je veux, non?

 mysql> GRANT ALL PRIVILEGES ON *.* TO 'steves'@'[hostname].com' IDENTIFIED BY '[OBSCURED]' WITH GRANT OPTION; ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) 

Comment pourrais-je avoir foiré quelque chose de si basique?

Note: pour quiconque veut suggérer que je n’ai pas d’utilisateur nommé root avec tous les privilèges, c’est génial et je le considérerai une fois que je pourrai accorder des privilèges à un autre utilisateur.

Je vous remercie!

Remarquez comment la sortie de

 SHOW GRANTS FOR 'root'@'localhost'; 

n’a pas dit “ALL PRIVILEGES” mais a dû préciser ce que root @ localhost a.

Accorder tous les privilèges échouera, car un utilisateur ne peut pas accorder ce qu’il / elle n’a pas, et le serveur semble penser que quelque chose n’est pas là …

Maintenant, qu’est-ce qui manque alors?

Sur mon système, je reçois ceci:

 mysql> select version(); +------------+ | version() | +------------+ | 5.5.21-log | +------------+ 1 row in set (0.00 sec) mysql> SHOW GRANTS FOR 'root'@'localhost'; +---------------------------------------------------------------------+ | Grants for root@localhost | +---------------------------------------------------------------------+ | GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION | | GRANT PROXY ON ''@'' TO 'root'@'localhost' WITH GRANT OPTION | +---------------------------------------------------------------------+ 2 rows in set (0.00 sec) mysql> SELECT * FROM mysql.user WHERE User='root' and Host='localhost'\G *************************** 1. row *************************** Host: localhost User: root Password: Select_priv: Y Insert_priv: Y Update_priv: Y Delete_priv: Y Create_priv: Y Drop_priv: Y Reload_priv: Y Shutdown_priv: Y Process_priv: Y File_priv: Y Grant_priv: Y References_priv: Y Index_priv: Y Alter_priv: Y Show_db_priv: Y Super_priv: Y Create_tmp_table_priv: Y Lock_tables_priv: Y Execute_priv: Y Repl_slave_priv: Y Repl_client_priv: Y Create_view_priv: Y Show_view_priv: Y Create_routine_priv: Y Alter_routine_priv: Y Create_user_priv: Y Event_priv: Y Trigger_priv: Y Create_tablespace_priv: Y <----------------------------- new column in 5.5 ssl_type: ssl_cipher: x509_issuer: x509_subject: max_questions: 0 max_updates: 0 max_connections: 0 max_user_connections: 0 plugin: <------------------------------- new column in 5.5 authentication_string: <------------------------------- new column in 5.5 1 row in set (0.00 sec) 

Il existe également de nouvelles tables en 5.5, telles que mysql.proxies_user: assurez-vous de les avoir.

Lors de l'installation d'une nouvelle instance de serveur mysql, le script d'installation créera toutes les tables mysql. * Avec la structure appropriée.

Lors de la mise à niveau à partir d'une ancienne version, assurez-vous que la procédure de mise à niveau appropriée (mysql_upgrade) est utilisée, ce qui appenda les tables / colonnes manquantes.

Ce n'est qu'une supposition, mais il semble que mysql_upgrade n'a pas été fait pour cette instance, provoquant le comportement vu.

J’ai aussi eu le même problème avec Windows après la mise à jour vers MySQL 5.5 depuis MySQL 5.1. J’ai déjà essayé de changer, de créer et de réinitialiser le mot de passe mentionné ici , ici , ici et ici , aucun indice. Je reçois toujours la même erreur:

 ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES) 

Je peux me connecter normalement, afficher toutes les bases de données, faire des sélections et des insertions, créer et append des utilisateurs, mais quand il s’agit de GRANT, je suis foutu. Les erreurs d’access refusé apparaissent à nouveau.

J’ai réussi à résoudre ce problème en fixant les privilèges par la commande suivante sur le répertoire bin / server de MySQL, comme indiqué ici :

 C:\MySQL Server 5.5\bin> mysql_upgrade 

Ensuite, le problème a disparu. J’espère que cette solution fonctionne aussi sur Linux puisque généralement MySQL fournit la même commande sous Linux et Windows.

Cela peut se produire lorsque vous tentez d’accorder tous les privilèges sur toutes les tables à un autre utilisateur, car la table mysql.users est considérée comme interdite à un utilisateur autre que root.

Ce qui suit devrait cependant fonctionner:

 GRANT ALL PRIVILEGES ON `%`.* TO '[user]'@'[hostname]' IDENTIFIED BY '[password]' WITH GRANT OPTION; 

Notez que nous utilisons `%`. * Au lieu de *. *

Cela m’est arrivé lorsque j’ai essayé d’installer une version MySQL supérieure à celle fournie avec la dissortingbution.

J’ai effacé l’ancienne version puis installé la nouvelle (rpm -e … puis rpm -i MySQL-server *) mais je ne savais pas que les fichiers de / var / lib / mysql étaient toujours de l’ancienne version (avec des différences expliqué par Marc Alff – merci!)

J’aurais pu faire un mysql_upgrade, mais comme je voulais partir de zéro, j’ai fait:

 # su - mysql $ rm -rf /var/lib/mysql/* $ mysql_install_db # /etc/init.d/mysql start 

Ensuite, définissez le mot de passe root (/ usr / bin / mysqladmin -u mot de passe root), et tout fonctionnait comme prévu avec les commandes GRANT …

J’ai eu le même problème, à savoir tous les privilèges accordés pour root:

 SHOW GRANTS FOR 'root'@'localhost'\G *************************** 1. row *************************** Grants for root@localhost: GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY PASSWORD '*[blabla]' WITH GRANT OPTION 

… mais pas encore autorisé à créer un tableau:

  create table t3(id int, txt varchar(50), primary key(id)); ERROR 1142 (42000): CREATE command denied to user 'root'@'localhost' for table 't3' 

Eh bien, cela était dû à une erreur d’utilisateur ennuyeuse, c’est-à-dire que je n’ai pas sélectionné de firebase database. Après avoir émis USE nom_base, cela fonctionnait bien.

Taper SHOW GRANTS FOR 'root'@'localhost'; m’a montré un mot de passe obscurci, donc je me suis connecté à mysql de ce système en utilisant HeidiSQL sur un autre système (en utilisant root comme nom d’utilisateur et le mot de passe correspondant) et en tapant
GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'thepassword' WITH GRANT OPTION;

et cela a fonctionné lorsque je suis retourné au système et connecté en utilisant
mysql -uroot -pthepassword;

Fondamentalement, cette erreur survient lorsque vous n’avez pas spécifié de mot de passe, cela signifie que vous avez un mot de passe incorrect répertorié dans un fichier d’options.

Lisez ce document pour savoir comment atsortingbuer et gérer les mots de passe aux comptes.

Vérifiez également si l’autorisation sur le dossier /var/lib/mysql/mysql est 711 ou non.

Sur Debian ( Wheezy , 7.8) avec MySQL 5.5.40, j’ai trouvé SELECT * FROM mysql.user WHERE User='root'\G montrait que les Event_priv et ‘Trigger_priv` étaient présents mais non définis sur Y.

L’exécution de mysql_upgrade (avec ou sans --force ) n’a fait aucune différence. Je devais faire un manuel:

update user set Event_priv = 'Y',Trigger_priv = 'Y' where user = 'root'

Alors enfin je pourrais utiliser:

GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' IDENTIFIED BY 'password' WITH GRANT OPTION

… Et ensuite l’utiliser plus précisément sur une firebase database / un compte utilisateur individuel.

Je cours à cela lorsque j’ai essayé d’append des privilèges à performance_schema, qui est le bogue mysql http://bugs.mysql.com/bug.php?id=44898 (solution pour append –single-transaction).

Pour ceux qui se heurtent encore à ce problème, il vaut mieux vérifier que la tentative GRANT n’existe pas déjà:

 SHOW GRANTS FOR username; 

Dans mon cas, l’erreur n’était pas réellement due à une erreur de permission, mais parce que le GRANT existait déjà.

J’ai eu le même problème et il a fallu beaucoup de lecture des messages SO et de la documentation de Google. J’ai finalement trouvé cela dans la FAQ Cloud SQL :

Google Cloud SQL ne prend pas en charge les privilèges SUPER, ce qui signifie que les instructions GRANT ALL PRIVILEGES ne fonctionneront pas. Comme alternative, vous pouvez utiliser GRANT ALL ON `%`.*

Vous êtes peut-être arrivé à cette question avec MySQL version 8 installée (comme moi) et vous n’avez pas trouvé de réponse satisfaisante. Vous ne pouvez plus créer d’utilisateurs comme celui-ci dans la version 8:

 GRANT ALL PRIVILEGES ON *.* TO 'steves'@'[hostname].com' IDENTIFIED BY '[OBSCURED]' WITH GRANT OPTION; 

Le message d’erreur plutôt déroutant que vous obtenez est le suivant: ERROR 1410 (42000): You are not allowed to create a user with GRANT

Pour créer des utilisateurs dans la version 8, vous devez le faire en deux étapes:

 CREATE USER 'steves'@'[hostname].com' IDENTIFIED BY '[OBSCURED]'; GRANT ALL PRIVILEGES ON *.* TO 'steves'@'[hostname].com' WITH GRANT OPTION; 

Bien sûr, si vous préférez, vous pouvez également fournir un nombre limité de privilèges (au lieu de GRANT ALL PRIVILEGES ), par exemple GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, ALTER