To zależy od tego, jak zdefiniujesz „wszystkie przeczytane”.
"Czytanie" z tabel i widoków to SELECT przywilej. Jeśli to masz na myśli, mówiąc „wszystkie przeczytane”, to tak:
GRANT SELECT ON *.* TO 'username'@'host_or_wildcard' IDENTIFIED BY 'password';
Jednak brzmi to tak, jakbyś miał na myśli zdolność „widzenia” wszystkiego, „patrzenia, ale nie dotykania”. Oto inne rodzaje czytania, które przychodzą mi do głowy:
"Czytanie" definicji widoków to SHOW VIEW przywilej.
"Odczytywanie" listy aktualnie wykonywanych zapytań przez innych użytkowników to PROCESS przywilej.
„Odczytywanie” bieżącego stanu replikacji to REPLICATION CLIENT przywilej.
Pamiętaj, że niektóre lub wszystkie z nich mogą ujawnić więcej informacji, niż zamierzasz ujawnić, w zależności od charakteru danego użytkownika.
Jeśli to jest czytanie, które chcesz zrobić, możesz połączyć dowolne z nich (lub dowolne inne z dostępne uprawnienia
) w jednym GRANT oświadczenie.
GRANT SELECT, SHOW VIEW, PROCESS, REPLICATION CLIENT ON *.* TO ...
Jednak nie ma jednego przywileju, który zapewnia pewien podzbiór innych przywilejów, o co wygląda na to, że o to prosisz.
Jeśli robisz rzeczy ręcznie i szukasz prostszego sposobu na zrobienie tego bez konieczności zapamiętywania dokładnego grantu, który zwykle robisz dla określonej klasy użytkownika, możesz wyszukać instrukcję, aby ponownie wygenerować granty porównywalnego użytkownika i zmienić je aby utworzyć nowego użytkownika z podobnymi uprawnieniami:
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)
Zmiana 'not_leet' i 'localhost' tak, aby odpowiadały nowemu użytkownikowi, którego chcesz dodać, wraz z hasłem, spowoduje ponowne użycie GRANT oświadczenie, aby utworzyć nowego użytkownika.
Jeśli chcesz, aby pojedyncza operacja skonfigurowała i przyznała ograniczony zestaw uprawnień użytkownikom i być może usunęła wszelkie niezasłużone uprawnienia, można to zrobić, tworząc procedurę składowaną, która hermetyzuje wszystko, co chcesz zrobić. W treści procedury utworzyłbyś GRANT instrukcji z dynamicznym SQL i/lub bezpośrednio manipuluj samymi tabelami grantów.
W ostatnim pytaniu dotyczącym administratorów baz danych
autor chciał mieć możliwość modyfikowania innych użytkowników przez nieuprzywilejowanego użytkownika, co oczywiście nie jest czymś, co normalnie można zrobić – użytkownik, który może modyfikować innych użytkowników, z definicji nie jest użytkownikiem nieuprzywilejowanym – jednak – - procedury składowane są dobrym rozwiązaniem w tym przypadku, ponieważ działają z kontekstem bezpieczeństwa ich DEFINER użytkownika, zezwalając każdemu z EXECUTE uprawnienia do procedury, aby tymczasowo przejąć eskalowane uprawnienia, aby umożliwić im wykonywanie określonych czynności, które wykonuje procedura.
