S'il existe un seul privilège qui correspond à TOUTES les opérations de lecture sur la base de données.
Cela dépend de la façon dont vous définissez «tout lu».
"Lire" à partir de tables et de vues est le SELECT
privilège. Si c'est ce que vous entendez par «tous lus», alors oui:
GRANT SELECT ON *.* TO 'username'@'host_or_wildcard' IDENTIFIED BY 'password';
Cependant, on dirait que vous voulez dire une capacité à «voir» tout, à «regarder mais pas toucher». Alors, voici les autres types de lecture qui me viennent à l'esprit:
"Lire" la définition des vues est le SHOW VIEW
privilège.
"Lire" la liste des requêtes en cours d'exécution par d'autres utilisateurs est le PROCESS
privilège.
"Lire" l'état de réplication actuel est le REPLICATION CLIENT
privilège.
Notez que tout ou partie de ces éléments peut exposer plus d'informations que vous ne comptez exposer, selon la nature de l'utilisateur en question.
Si c'est la lecture que vous voulez faire, vous pouvez combiner n'importe lequel de ceux-ci (ou tout autre des privilèges disponibles ) dans une seule GRANT
instruction.
GRANT SELECT, SHOW VIEW, PROCESS, REPLICATION CLIENT ON *.* TO ...
Cependant, il n'y a pas de privilège unique qui accorde un sous-ensemble d'autres privilèges, ce que vous semblez demander.
Si vous faites les choses manuellement et que vous recherchez un moyen plus simple de procéder sans avoir à vous souvenir de la subvention exacte que vous accordez généralement à une certaine classe d'utilisateurs, vous pouvez rechercher l'instruction pour régénérer les subventions d'un utilisateur comparable et la modifier. pour créer un nouvel utilisateur avec des privilèges similaires:
mysql> SHOW GRANTS FOR 'not_leet'@'localhost';
+------------------------------------------------------------------------------------------------------------------------------------+
| Grants for not_leet@localhost |
+------------------------------------------------------------------------------------------------------------------------------------+
| GRANT SELECT, REPLICATION CLIENT ON *.* TO 'not_leet'@'localhost' IDENTIFIED BY PASSWORD '*xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx' |
+------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)
Changer «not_leet» et «localhost» pour correspondre au nouvel utilisateur que vous souhaitez ajouter, avec le mot de passe, entraînera une GRANT
instruction réutilisable pour créer un nouvel utilisateur.
De, si vous souhaitez qu'une seule opération configure et accorde le jeu limité de privilèges aux utilisateurs, et peut-être supprimer tous les privilèges non mérités, cela peut être fait en créant une procédure stockée qui encapsule tout ce que vous voulez faire. Dans le corps de la procédure, vous construisez l' GRANT
instruction avec du SQL dynamique et / ou manipulez directement les tables d'octroi elles-mêmes.
Dans cette question récente sur les administrateurs de base de données , l'affiche voulait la possibilité pour un utilisateur non privilégié de modifier d'autres utilisateurs, ce qui, bien sûr, n'est pas quelque chose qui peut normalement être fait - un utilisateur qui peut modifier d'autres utilisateurs est, à peu près par définition, non un utilisateur non privilégié - cependant - les procédures stockées ont fourni une bonne solution dans ce cas, car elles s'exécutent avec le contexte de sécurité de leur DEFINER
utilisateur, permettant à toute personne disposant de EXECUTE
privilèges sur la procédure d'assumer temporairement des privilèges accrus pour leur permettre de faire les choses spécifiques la procédure accomplit.
SHOW VIEW
nonSHOW_VIEW
, mais vous n'avez pas besoin de l'accorder à un utilisateur à moins que vous ne vouliez qu'il puisse le faireSHOW CREATE VIEW
sur les vues ... ils peuvent sélectionner parmi les vues avec le seulSELECT
privilège. Qu'entendez-vous par «regrouper toutes les opérations de lecture dans la concession»?