Зависи как дефинирате „всички прочетени“.
"Четенето" от таблици и изгледи е SELECT привилегия. Ако това имате предвид под „всички прочетени“, тогава да:
GRANT SELECT ON *.* TO 'username'@'host_or_wildcard' IDENTIFIED BY 'password';
Въпреки това звучи така, сякаш имате предвид способност да „виждате“ всичко, да „гледате, но не докосвате“. И така, ето другите видове четене, които идват на ум:
"Четене" на дефиницията на изгледите е SHOW VIEW привилегия.
"Четене" на списъка с изпълнявани в момента заявки от други потребители е PROCESS привилегия.
"Четене" на текущото състояние на репликация е REPLICATION CLIENT привилегия.
Имайте предвид, че някои или всички от тях може да разкрият повече информация, отколкото възнамерявате да разкриете, в зависимост от естеството на въпросния потребител.
Ако това е четенето, което искате да направите, можете да комбинирате някое от тях (или всеки друг от достъпните привилегии
) в един GRANT изявление.
GRANT SELECT, SHOW VIEW, PROCESS, REPLICATION CLIENT ON *.* TO ...
Въпреки това, няма единна привилегия, която предоставя някои подмножества от други привилегии, което звучи така, сякаш питате.
Ако правите нещата ръчно и търсите по-лесен начин да направите това, без да е необходимо да помните точното разрешение, което обикновено давате за определен клас потребители, можете да потърсите изявлението, за да генерирате повторно съпоставими потребителски безвъзмездни средства и да го промените за да създадете нов потребител с подобни привилегии:
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)
Промяната на „not_leet“ и „localhost“, за да съответстват на новия потребител, който искате да добавите, заедно с паролата, ще доведе до повторно използваем GRANT изявление за създаване на нов потребител.
Или ако искате една операция да настроите и предоставите ограничен набор от привилегии на потребителите и може би да премахнете всички незаслужени привилегии, това може да стане чрез създаване на съхранена процедура, която капсулира всичко, което искате да правите. В тялото на процедурата ще изградите GRANT оператор с динамичен SQL и/или директно манипулиране на самите таблици за предоставяне.
В този скорошен въпрос за администратори на бази данни
, плакатът искаше възможността непривилегирован потребител да променя други потребители, което, разбира се, не е нещо, което обикновено може да се направи - потребител, който може да променя други потребители, почти по дефиниция не е непривилегирован потребител - обаче - - съхранените процедури предоставят добро решение в този случай, тъй като се изпълняват с контекста на сигурността на техния DEFINER потребител, позволявайки на всеки с EXECUTE привилегия върху процедурата, за да поеме временно повишени привилегии, за да им позволи да правят конкретните неща, които процедурата изпълнява.
