web-dev-qa-db-fra.com

Réattribuer l'autorisation d'accès à l'hôte à l'utilisateur MySQL

J'ai plusieurs milliers d'utilisateurs MySQL prêts à autoriser l'accès à partir d'un hôte spécifique. Le problème est que maintenant je vais avoir deux machines (plus à l'avenir) qui devront utiliser le même compte pour accéder à chacune de leurs bases de données.

Je voudrais un moyen rapide et facile (aussi automatisé que possible) de parcourir et de modifier la partie hôte de chaque compte d'utilisateur pour l'adapter à un caractère générique de réseau interne. Par exemple:

'bugsy' @ 'internalfoo' a accès à la base de données 'bugsy'.

Je veux maintenant autoriser l'accès à Bugsy depuis n'importe où sur le réseau interne

'bugsy'@'10.0.0.%' a accès à la base de données 'bugsy'.

mysqlpermissions
56
Nick Jennings

Pour référence, la solution est:

UPDATE mysql.user SET Host = '10.0.0.%' WHERE Host = 'internalfoo' AND user != 'root';
UPDATE mysql.db SET Host = '10.0.0.%' WHERE Host = 'internalfoo' AND user != 'root';
FLUSH PRIVILEGES;
111
Nick Jennings

La réponse acceptée a seulement renommé l'utilisateur, mais les privilèges ont été abandonnés.

Je recommanderais d'utiliser:

RENAME USER 'foo'@'1.2.3.4' TO 'foo'@'1.2.3.5';

Selon documentation MySQL :

RENOMMER UTILISATEUR fait que les privilèges détenus par l'ancien utilisateur sont ceux détenus par le nouvel utilisateur.

84
Pedro

La réponse plus générale est

UPDATE mysql.user SET Host = {newhost} WHERE user = {youruser}
5
e18r

Je n'ai pas eu à faire cela, alors prenez-le avec un grain de sel et une grosse portion de "test, test, test".

Que se passe-t-il si (dans un environnement de test contrôlé sécurisé) vous modifiez directement la colonne Host dans le mysql.user et probablement mysql.db les tables? (Par exemple, avec une instruction update.) Je ne pense pas que MySQL utilise l'hôte de l'utilisateur dans le cadre de l'encodage du mot de passe (la fonction PASSWORD ne le suggère pas), mais vous ' Je vais devoir l'essayer pour en être sûr. Vous devrez peut-être émettre un FLUSH PRIVILEGES commande (ou arrêtez et redémarrez le serveur).

Pour certains moteurs de stockage (MyISAM, par exemple), vous devrez peut-être également vérifier/modifier le .frm fichier toutes les vues que l'utilisateur a créées. Le .frm Le fichier stocke le définisseur, y compris l'hôte du définisseur. (J'ai dû faire cela, lors du déplacement de bases de données entre des hôtes où il y avait une mauvaise configuration provoquant l'enregistrement du mauvais hôte ...)

1
T.J. Crowder

Un problème similaire où j'obtenais des autorisations a échoué. Sur ma configuration, je SSH uniquement. Donc, ce que j'ai fait pour corriger le problème était

Sudo MySQL
SELECT User, Host FROM mysql.user WHERE Host <> '%';
MariaDB [(none)]> SELECT User, Host FROM mysql.user WHERE Host <> '%';
+-------+-------------+
| User  | Host        |
+-------+-------------+
| root  | 169.254.0.% |
| foo   | 192.168.0.% |
| bar   | 192.168.0.% |
+-------+-------------+
4 rows in set (0.00 sec)

J'ai besoin que ces utilisateurs soient déplacés vers "localhost". J'ai donc émis ce qui suit:

UPDATE mysql.user SET Host = 'localhost' WHERE user = 'foo';
UPDATE mysql.user SET Host = 'localhost' WHERE user = 'bar';

Exécutez SELECT User, Host FROM mysql.user WHERE Host <> '%'; encore une fois et nous voyons:

MariaDB [(none)]> SELECT User, Host FROM mysql.user WHERE Host <> '%';
+-------+-------------+
| User  | Host        |
+-------+-------------+
| root  | 169.254.0.% |
| foo   | localhost   |
| bar   | localhost   |
+-------+-------------+
4 rows in set (0.00 sec)

Et puis j'ai pu de nouveau travailler normalement. J'espère que cela aide quelqu'un.

$ mysql -u foo -p
Enter password:
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 74
Server version: 10.1.23-MariaDB-9+deb9u1 Raspbian 9.0

Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [(none)]>
1
jhayton

J'ai reçu la même erreur avec RENAME USER et GRANTS ne sont pas couverts par la solution actuellement acceptée:

Le moyen le plus fiable semble être d'exécuter SHOW GRANTS pour l'ancien utilisateur, recherchez/remplacez ce que vous voulez changer concernant le nom de l'utilisateur et/ou l'hôte et exécutez-les puis enfin DROP USER l'ancien utilisateur. Sans oublier d'exécuter FLUSH PRIVILEGES (préférable d'exécuter ceci après avoir ajouté les autorisations des nouveaux utilisateurs, tester le nouvel utilisateur, puis supprimer l'ancien utilisateur et vider à nouveau pour faire bonne mesure).

> AFFICHER LES SUBVENTIONS POUR 'olduser' @ 'oldhost'; 
 + --------------------------- -------------------------------------------------- ------ + 
 | Subventions pour olduser @ oldhost | 
 + -------------------------------------- --------------------------------------------- + 
 | DONNER L'UTILISATION SUR *. * À 'olduser' @ 'oldhost' IDENTIFIÉ PAR MOT DE PASSE '* PASSHASH' | 
 | GRANT SELECT ON `db`. * TO 'olduser' @ 'oldhost' | 
 + --------------------------- -------------------------------------------------- ------ + 
 2 lignes dans l'ensemble (0,000 sec) 
 
> ACCORDER L'UTILISATION SUR *. * À 'newuser' @ 'newhost' IDENTIFIED BY PASSWORD '* SAME_PASSHASH '; 
 Requête OK, 0 lignes affectées (0,006 sec) 
 
> GRANT SELECT ON `db`. * TO' newuser '@' newhost '; 
 Requête OK, 0 lignes affectées (0,007 s) 
 
> DROP USER 'olduser' @ 'oldhost'; 
 Requête OK, 0 lignes affectées (0,016 sec)
0
CrackerJack9