Dipende da come definisci "tutti letti".
La "lettura" da tabelle e viste è il SELECT privilegio. Se è questo che intendi con "tutti letti", allora sì:
GRANT SELECT ON *.* TO 'username'@'host_or_wildcard' IDENTIFIED BY 'password';
Tuttavia, sembra che tu intenda la capacità di "vedere" tutto, di "guardare ma non toccare". Quindi, ecco gli altri tipi di lettura che mi vengono in mente:
"Leggere" la definizione delle viste è il SHOW VIEW privilegio.
"Leggere" l'elenco delle query attualmente in esecuzione da parte di altri utenti è il PROCESS privilegio.
La "lettura" dello stato di replica corrente è il REPLICATION CLIENT privilegio.
Tieni presente che alcuni o tutti questi potrebbero esporre più informazioni di quelle che intendi esporre, a seconda della natura dell'utente in questione.
Se questa è la lettura che vuoi fare, puoi combinare una di queste (o qualsiasi altra di i privilegi disponibili
) in un unico GRANT dichiarazione.
GRANT SELECT, SHOW VIEW, PROCESS, REPLICATION CLIENT ON *.* TO ...
Tuttavia, non esiste un unico privilegio che conceda un sottoinsieme di altri privilegi, come sembra che tu stia chiedendo.
Se stai facendo le cose manualmente e stai cercando un modo più semplice per farlo senza dover ricordare l'esatta concessione che di solito fai per una certa classe di utenti, puoi cercare la dichiarazione per rigenerare le sovvenzioni di un utente comparabile e cambiarla in giro per creare un nuovo utente con privilegi simili:
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)
La modifica di "not_leet" e "localhost" in modo che corrisponda al nuovo utente che desideri aggiungere, insieme alla password, risulterà in un GRANT riutilizzabile dichiarazione per creare un nuovo utente.
Di, se si desidera una singola operazione per impostare e concedere il set limitato di privilegi agli utenti, e forse rimuovere eventuali privilegi immeritati, è possibile farlo creando una procedura memorizzata che incapsula tutto ciò che si desidera fare. All'interno del corpo della procedura, creeresti il GRANT istruzione con SQL dinamico e/o manipolare direttamente le tabelle di concessione stesse.
In questa recente domanda sugli amministratori di database
, il poster voleva la possibilità per un utente non privilegiato di modificare altri utenti, il che ovviamente non è qualcosa che può essere fatto normalmente -- un utente che può modificare altri utenti è, più o meno per definizione, non un utente senza privilegi -- tuttavia - - le stored procedure hanno fornito una buona soluzione in quel caso, perché vengono eseguite con il contesto di sicurezza del loro DEFINER utente, consentendo a chiunque abbia EXECUTE privilegio sulla procedura per assumere temporaneamente privilegi escalation per consentire loro di fare le cose specifiche che la procedura compie.
