Cela dépend de la façon dont vous définissez "tous lus".
"Lecture" des tables et des 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, il semble que vous parliez d'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.
"Reading" l'état actuel de la réplication est le REPLICATION CLIENT privilège.
Notez que tout ou partie de ceux-ci peuvent exposer plus d'informations que vous n'avez l'intention d'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 n'importe quel autre de les privilèges disponibles
) en un seul GRANT déclaration.
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, c'est ce que vous semblez demander.
Si vous faites les choses manuellement et que vous cherchez 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 la déclaration 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 [email protected] |
+------------------------------------------------------------------------------------------------------------------------------------+
| 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, ainsi que le mot de passe, entraînera un GRANT réutilisable déclaration pour créer un nouvel utilisateur.
Bien sûr, si vous souhaitez qu'une seule opération configure et accorde l'ensemble limité de privilèges aux utilisateurs, et peut-être supprimez 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 construiriez le GRANT avec SQL dynamique et/ou manipuler directement les tables de droits 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 n'est, à peu près par définition, pas 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 à quiconque avec EXECUTE privilège sur la procédure pour assumer temporairement des privilèges élevés pour leur permettre de faire les choses spécifiques que la procédure accomplit.
