J'ai un compte utilisateur - appelons-le "wordpress" - que je dois autoriser à accéder à quelques tables de catalogue dans une autre base de données de commerce électronique sur le même serveur. J'ai configuré l'utilisateur avec trois masques d'hôte à partir desquels il est autorisé à se connecter: 'localhost', l'adresse IP du serveur Web et le nom d'hôte du serveur Web. Aucun problème là-bas.
L'utilisateur "wordpress" a également un accès complet à sa propre base de données, accordée via la section Privilèges de schéma dans MySQL Workbench. Ici, cela montre que l'hôte est '%', ce que je veux, car je ne veux pas gérer trois jeux de privilèges en double pour le même utilisateur. Si je regarde dans mysql.db, je vois ces privilèges, avec '%' dans la colonne Host.
Alors maintenant, je veux accorder l'autorisation SELECT sur une poignée de tables dans une autre base de données - appelons-la "stocker". J'essaye donc ceci:
GRANT SELECT ON store.catalog TO 'wordpress'@'%';
Et j'obtiens "Impossible de trouver une ligne correspondante dans la table utilisateur", pour la raison évidente que "%" n'est pas un masque d'hôte dont j'ai explicitement autorisé une connexion pour cet utilisateur particulier. Quelle est donc la syntaxe appropriée pour accorder un privilège de table à un utilisateur à partir de l'un de ses masques hôtes autorisés? Comment MySQL Workbench s'en sort-il avec les privilèges de schéma? Je n'ai pas besoin d'insérer manuellement des lignes dans mysql.tables_priv, n'est-ce pas?
UPDATE : Pour clarifier, voici à quoi ressemblent les tables utilisateur/octroi actuelles. J'ai anonymisé certains noms, évidemment. Notez que l'hôte dans la table de privilèges de schéma est '%', mais il n'y a aucun utilisateur avec cet hôte. Comment puis-je obtenir MySQL pour me permettre de le faire avec des octrois d'objet de schéma? De préférence sans contourner directement dans mysql.tables_priv, mais je le ferai si cela se résume à cela.
mysql> SELECT user, Host FROM mysql.user WHERE user = 'wordpress';
+-----------+-----------+
| user | Host |
+-----------+-----------+
| wordpress | 10.0.0.22 |
| wordpress | webserver |
| wordpress | localhost |
+-----------+-----------+
3 rows in set (0.00 sec)
mysql> SELECT user, Host, db, select_priv FROM mysql.db WHERE User = 'wordpress';
+-----------+------+----------------+-------------+
| user | Host | db | select_priv |
+-----------+------+----------------+-------------+
| wordpress | % | wordpress | Y |
| wordpress | % | wordpress_test | Y |
+-----------+------+----------------+-------------+
2 rows in set (0.00 sec)
mysql> SHOW GRANTS FOR 'wordpress'@'localhost';
+---------------------------------------------------------------------------+
| Grants for wordpress@localhost |
+---------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'wordpress'@'localhost' IDENTIFIED BY PASSWORD '--' |
+---------------------------------------------------------------------------+
1 row in set (0.00 sec)
mysql> SHOW GRANTS FOR 'wordpress'@'%';
ERROR 1141 (42000): There is no such grant defined for user 'wordpress' on Host '%'
MySQL Workbench fait-il quelque chose d'horriblement non documenté avec des privilèges de schéma/objet? Juste pour les coups de pied, j'ai accordé certains privilèges de table à l'une des combinaisons utilisateur @ hôte spécifiques, puis j'ai mis à jour mysql.tables_priv pour changer l'hôte en '%'. Après avoir exécuté FLUSH PRIVILEGES, cela a fonctionné parfaitement. Bizarre.
Lorsque vous exécutez GRANT SELECT ON store.catalog TO 'wordpress'@'%';
, mysqld veut insérer une ligne dans la table de subvention mysql.tables_priv
. Voici mysql.tables_priv:
mysql> show create table mysql.tables_priv\G
*************************** 1. row ***************************
Table: tables_priv
Create Table: CREATE TABLE `tables_priv` (
`Host` char(60) COLLATE utf8_bin NOT NULL DEFAULT '',
`Db` char(64) COLLATE utf8_bin NOT NULL DEFAULT '',
`User` char(16) COLLATE utf8_bin NOT NULL DEFAULT '',
`Table_name` char(64) COLLATE utf8_bin NOT NULL DEFAULT '',
`Grantor` char(77) COLLATE utf8_bin NOT NULL DEFAULT '',
`Timestamp` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`Table_priv` set('Select','Insert','Update','Delete','Create','Drop','Grant','References','Index','Alter','Create View','Show view','Trigger') CHARACTER SET utf8 NOT NULL DEFAULT '',
`Column_priv` set('Select','Insert','Update','References') CHARACTER SET utf8 NOT NULL DEFAULT '',
PRIMARY KEY (`Host`,`Db`,`User`,`Table_name`),
KEY `Grantor` (`Grantor`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 COLLATE=utf8_bin COMMENT='Table privileges'
1 row in set (0.00 sec)
mysql>
Puisque vous souhaitez insérer une ligne dans mysql.table_priv
où user = 'wordpress' et Host = '%', il doit exister une ligne dans mysql.user
où user = 'wordpress' et Host = '%'.
Vous avez également mentionné que vous utilisez MySQL Workbench. Vous devez utiliser 'root'@'localhost'
. Cela aurait généralement tous les droits et un mot de passe.
Si vous souhaitez autoriser uniquement SELECT anonyme sur cette table, exécutez d'abord ceci:
GRANT USAGE ON *.* TO 'wordpress'@'%';
Cela placera wordpress@'%'
en mysql.user
. Ensuite, GRANT SELECT ON store.catalog TO 'wordpress'@'%'
devrait fonctionner correctement.
Vous devrez voir quelles autres entrées wordpress se trouvent dans mysql.user
. Cela devrait indiquer les commandes SQL GRANT dont vous avez besoin:
SELECT CONCAT('GRANT SELECT ON store.catalog TO ',userhost,';') GrantCommand
FROM
(
SELECT CONCAT('''',user,'''@''',Host,'''') userhost
FROM mysql.user WHERE user='wordpress'
) A;
Cela a fonctionné pour moi en utilisant la ligne de commande (pas le plan de travail):
mysql> GRANT SELECT ON foo.bar TO 'wordpress'@'%';
Query OK, 0 rows affected (0.07 sec)
mysql> SHOW GRANTS FOR wordpress@'%';
+------------------------------------------------+
| Grants for wordpress@% |
+------------------------------------------------+
| GRANT USAGE ON *.* TO 'wordpress'@'%' |
| GRANT SELECT ON `foo`.`bar` TO 'wordpress'@'%' |
+------------------------------------------------+
2 rows in set (0.05 sec)
J'ai fouillé et trouvé ceci rapport de bogue . Quelle version est votre Workbench? Il semble qu'ils aient un correctif, mais n'étant pas un utilisateur de Workbench, je ne connais pas leur version (la version actuelle devrait être corrigée).
Même si ce n'est pas le cas, la solution consiste à l'exécuter via la ligne de commande!