Det afhænger af, hvordan du definerer "alt læst."
"Læsning" fra tabeller og visninger er SELECT privilegium. Hvis det er det du mener med "alle læst", så ja:
GRANT SELECT ON *.* TO 'username'@'host_or_wildcard' IDENTIFIED BY 'password';
Det lyder dog som om du mener en evne til at "se" alt, at "se, men ikke røre." Så her er de andre former for læsning, der kommer til at tænke på:
At "læse" definitionen af visninger er SHOW VIEW privilegium.
At "læse" listen over aktuelt udførende forespørgsler fra andre brugere er PROCESS privilegium.
"Læser" den aktuelle replikeringstilstand er REPLICATION CLIENT privilegium.
Bemærk, at en eller flere af disse kan afsløre flere oplysninger, end du har til hensigt at afsløre, afhængigt af arten af den pågældende bruger.
Hvis det er den læsning, du vil gøre, kan du kombinere enhver af disse (eller en hvilken som helst anden af de tilgængelige privilegier
) i en enkelt GRANT erklæring.
GRANT SELECT, SHOW VIEW, PROCESS, REPLICATION CLIENT ON *.* TO ...
Der er dog ikke et enkelt privilegium, der giver nogle undersæt af andre privilegier, hvilket er hvad det lyder som om, du spørger om.
Hvis du gør tingene manuelt og leder efter en nemmere måde at gøre dette på uden at skulle huske den nøjagtige bevilling, du typisk giver til en bestemt klasse af brugere, kan du slå erklæringen op for at genskabe en sammenlignelig brugers bevillinger og ændre den omkring for at oprette en ny bruger med lignende privilegier:
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)
Ændring af 'not_leet' og 'localhost' for at matche den nye bruger, du vil tilføje, sammen med adgangskoden, vil resultere i en genbrugelig GRANT erklæring for at oprette en ny bruger.
Hvis du vil have en enkelt handling til at opsætte og tildele det begrænsede sæt af privilegier til brugere, og måske fjerne eventuelle ufortjente privilegier, kan det gøres ved at oprette en lagret procedure, der indkapsler alt, hvad du ønsker at gøre. Inden for procedurens brødtekst skal du bygge GRANT sætning med dynamisk SQL og/eller direkte manipulere selve tildelingstabellerne.
I dette seneste spørgsmål om databaseadministratorer
, ønskede plakaten muligheden for en uprivilegeret bruger til at ændre andre brugere, hvilket naturligvis ikke er noget, der normalt kan gøres -- en bruger, der kan ændre andre brugere, er stort set per definition ikke en uprivilegeret bruger -- dog - - lagrede procedurer var en god løsning i det tilfælde, fordi de kører med sikkerhedskonteksten for deres DEFINER bruger, hvilket tillader enhver med EXECUTE privilegium på proceduren til midlertidigt at påtage sig eskalerede privilegier for at give dem mulighed for at gøre de specifikke ting, proceduren opnår.