Datenbanksicherheit ist für jedes MySQL-Setup wichtig. Benutzer sind die Grundlage jedes Systems. In Bezug auf Datenbanksysteme teile ich sie im Allgemeinen in zwei verschiedene Gruppen:
- Benutzer von Anwendungen, Diensten oder Programmen - im Wesentlichen Kunden oder Klienten, die einen Dienst nutzen.
- Datenbankentwickler, Administratoren, Analysten usw. … - Diejenigen, die die Datenbankinfrastruktur warten, mit ihr arbeiten oder sie überwachen.
Obwohl jeder Benutzer auf einer bestimmten Ebene auf die Datenbank zugreifen muss, sind diese Berechtigungen nicht alle gleich.
Beispielsweise benötigen Klienten und Kunden Zugriff auf die Daten ihrer „zugehörigen Benutzerkonten“, aber selbst das sollte mit einem gewissen Maß an Kontrolle überwacht werden. Einige Tabellen und Daten sollten jedoch streng tabu sein (z. B. Systemtabellen).
Trotzdem:
- Analyst benötigt 'Lesezugriff ', um Informationen und Einblicke durch Abfragen von Tabellen zu erhalten...
- Entwickler benötigen eine Reihe von Berechtigungen und Privilegien, um ihre Arbeit auszuführen …
- DBAs benötigen 'Root'- oder ähnliche Privilegien, um die Show auszuführen...
- Käufer eines Dienstes müssen ihren Bestell- und Zahlungsverlauf sehen...
Sie können sich vorstellen (ich weiß, dass ich es tue), wie schwierig es ist, mehrere Benutzer oder Benutzergruppen innerhalb eines Datenbank-Ökosystems zu verwalten.
In älteren MySQL-Versionen wird eine Mehrbenutzerumgebung auf etwas monotone und sich wiederholende Weise eingerichtet.
Dennoch implementiert Version 8 eine außergewöhnliche und leistungsstarke SQL-Standardfunktion - Rollen - , die einen der redundanteren Bereiche des gesamten Prozesses erleichtert:die Zuweisung von Privilegien an einen Benutzer.
Also, was ist eine Rolle in MySQL?
Sie können sicherlich MySQL in 2018:What’s in 8.0 and Other Observations besuchen, das ich hier für den Multiplenines-Blog geschrieben habe, wo ich Rollen für einen allgemeinen Überblick erwähne. Wo ich sie dort jedoch nur zusammengefasst habe, geht dieser aktuelle Beitrag tiefer und konzentriert sich ausschließlich auf Rollen.
So definiert die Online-MySQL-Dokumentation eine Rolle:"Eine MySQL-Rolle ist eine benannte Sammlung von Berechtigungen".
Scheint allein diese Definition nicht hilfreich zu sein?
Aber wie?
Wir werden in den folgenden Beispielen sehen.
Zur Kenntnisnahme der bereitgestellten Beispiele
Die in diesem Beitrag enthaltenen Beispiele beziehen sich auf eine persönliche „Einzelbenutzer“-Entwicklungs- und Lern-Workstation/-Umgebung, also stellen Sie sicher, dass Sie die Best Practices implementieren, die Ihnen für Ihre speziellen Bedürfnisse oder Anforderungen zugute kommen. Die gezeigten Benutzernamen und Passwörter sind rein willkürlich und schwach.
Benutzer und Berechtigungen in früheren Versionen
In MySQL 5.7 gibt es keine Rollen. Die Zuweisung von Berechtigungen zu Benutzern erfolgt individuell. Um besser zu verstehen, was Rollen bieten, verwenden wir sie nicht. Das macht überhaupt keinen Sinn, ich weiß. Aber im Laufe des Beitrags wird es passieren.
Nachfolgend erstellen wir einige Benutzer:
CREATE USER 'reader_1'@'localhost' IDENTIFIED BY 'some_password';
CREATE USER 'reader_writer'@'localhost' IDENTIFIED BY 'another_password';
CREATE USER 'changer_1'@'localhost' IDENTIFIED BY 'a_password';Dann werden diesen Benutzern einige Privilegien gewährt:
GRANT SELECT ON some_db.specific_table TO 'reader_1'@'localhost';
GRANT SELECT, INSERT ON some_db.specific_table TO 'reader_writer'@'localhost';
GRANT UPDATE, DELETE ON some_db.specific_table TO 'changer_1'@'localhost';Puh, froh, dass das vorbei ist. Nun zurück zu…
Und schon haben Sie eine Anfrage, zwei weitere „Nur-Lese“-Benutzer zu implementieren…
Zurück zum Reißbrett:
CREATE USER 'reader_2'@'localhost' IDENTIFIED BY 'password_2';
CREATE USER 'reader_3'@'localhost' IDENTIFIED BY 'password_3';Ihnen auch Privilegien zuweisen:
GRANT SELECT ON some_db.specific_table TO 'reader_2'@'localhost';
GRANT ALL ON some_db.specific_table TO 'reader_3'@'localhost';Können Sie erkennen, dass dies alles andere als produktiv, voller Wiederholungen und fehleranfällig ist? Aber was noch wichtiger ist, haben Sie den Fehler bemerkt?
Gut für dich!
Beim Gewähren von Berechtigungen für diese beiden zusätzlichen Benutzer habe ich versehentlich dem neuen Benutzer reader_3 ALLE Berechtigungen erteilt.
Hoppla.
Ein Fehler, den jeder machen kann.
MySQL-Rollen eingeben
Mit Rollen, vieles der oben genannten systematisch Die Zuweisung und Delegierung von Berechtigungen kann etwas gestrafft werden .
Die Benutzererstellung bleibt im Grunde gleich, aber die Zuweisung von Berechtigungen durch Rollen unterscheidet sich:
mysql> CREATE USER 'reader_1'@'localhost' IDENTIFIED BY 'some_password';
Query OK, 0 rows affected (0.19 sec)mysql> CREATE USER 'reader_writer'@'localhost' IDENTIFIED BY 'another_password';
Query OK, 0 rows affected (0.22 sec)mysql> CREATE USER 'changer_1'@'localhost' IDENTIFIED BY 'a_password';
Query OK, 0 rows affected (0.08 sec)mysql> CREATE USER 'reader_2'@'localhost' IDENTIFIED BY 'password_2';
Query OK, 0 rows affected (0.28 sec)mysql> CREATE USER 'reader_3'@'localhost' IDENTIFIED BY 'password_3';
Query OK, 0 rows affected (0.12 sec)Wenn Sie die Systemtabelle mysql.user abfragen, können Sie sehen, dass diese neu erstellten Benutzer existieren:
(Hinweis:Ich habe mehrere Benutzerkonten in dieser Lern-/Entwicklungsumgebung und habe einen Großteil der Ausgabe unterdrückt, um die Klarheit auf dem Bildschirm zu verbessern.)
mysql> SELECT User FROM mysql.user;
+------------------+
| User |
+------------------+
| changer_1 |
| mysql.infoschema |
| mysql.session |
| mysql.sys |
| reader_1 |
| reader_2 |
| reader_3 |
| reader_writer |
| root |
| | --multiple rows remaining here...
+------------------+
23 rows in set (0.00 sec)Ich habe diese willkürliche Tabelle und Beispieldaten:
mysql> SELECT * FROM name;
+--------+------------+
| f_name | l_name |
+--------+------------+
| Jim | Dandy |
| Johhny | Applesauce |
| Ashley | Zerro |
| Ashton | Zerra |
| Ashmon | Zerro |
+--------+------------+
5 rows in set (0.00 sec)Lassen Sie uns jetzt Rollen verwenden, um Privilegien für die neuen Benutzer einzurichten und zuzuweisen, um die Namenstabelle zu verwenden.
Erstellen Sie zuerst die Rollen:
mysql> CREATE ROLE main_read_only;
Query OK, 0 rows affected (0.11 sec)mysql> CREATE ROLE main_read_write;
Query OK, 0 rows affected (0.11 sec)mysql> CREATE ROLE main_changer;
Query OK, 0 rows affected (0.14 sec)Beachten Sie erneut die Tabelle mysql.user:
mysql> SELECT User FROM mysql.user;
+------------------+
| User |
+------------------+
| main_changer |
| main_read_only |
| main_read_write |
| changer_1 |
| mysql.infoschema |
| mysql.session |
| mysql.sys |
| reader_1 |
| reader_2 |
| reader_3 |
| reader_writer |
| root |
| |
+------------------+
26 rows in set (0.00 sec)Basierend auf dieser Ausgabe können wir vermuten; dass Rollen im Wesentlichen Benutzer selbst sind.
Als nächstes Rechtezuweisung:
mysql> GRANT SELECT ON practice.name TO 'main_read_only';
Query OK, 0 rows affected (0.14 sec)mysql> GRANT SELECT, INSERT ON practice.name TO 'main_read_write';
Query OK, 0 rows affected (0.07 sec)mysql> GRANT UPDATE, DELETE ON practice.name TO 'main_changer';
Query OK, 0 rows affected (0.16 sec)Ein kurzes Zwischenspiel
Warte eine Minute. Kann ich mich einfach anmelden und mit den Rollenkonten selbst irgendwelche Aufgaben erledigen? Schließlich sind sie Benutzer und haben die erforderlichen Rechte.
Versuchen wir, uns mit der Rolle main_changer:
bei der Übungsdatenbank anzumelden:~$ mysql -u main_changer -p practice
Enter password:
ERROR 1045 (28000): Access denied for user 'main_changer'@'localhost' (using password: YESDie einfache Tatsache, dass uns eine Passwortabfrage präsentiert wird, ist ein guter Hinweis darauf, dass dies (zumindest zu diesem Zeitpunkt) nicht möglich ist. Wie Sie sich erinnern, habe ich während ihrer Erstellung für keine der Rollen ein Passwort festgelegt.
Was hat die Spalte authentication_string der mysql.user-Systemtabellen zu sagen?
mysql> SELECT User, authentication_string, password_expired
-> FROM mysql.user
-> WHERE User IN ('main_read_only', 'root', 'main_read_write', 'main_changer')\G
*************************** 1. row ***************************
User: main_changer
authentication_string:
password_expired: Y
*************************** 2. row ***************************
User: main_read_only
authentication_string:
password_expired: Y
*************************** 3. row ***************************
User: main_read_write
authentication_string:
password_expired: Y
*************************** 4. row ***************************
User: root
authentication_string: ***various_jumbled_mess_here*&&*&*&*##
password_expired: N
4 rows in set (0.00 sec)Ich habe den Root-Benutzer in die Rollennamen für die IN()-Prädikatprüfung aufgenommen, um einfach zu demonstrieren, dass er eine authentication_string hat, wo die Rollen nicht vorhanden sind.
Diese Passage in der CREATE ROLE-Dokumentation verdeutlicht es gut:„Eine Rolle, wenn sie erstellt wird, ist gesperrt, hat kein Passwort und ihr wird das Standard-Authentifizierungs-Plugin zugewiesen. (Diese Rollenattribute können später mit der ALTER USER-Anweisung von Benutzern geändert werden, die die globales CREATE USER-Privileg.)"
Zurück zur eigentlichen Aufgabe, wir können den Benutzern jetzt die Rollen basierend auf ihren erforderlichen Berechtigungen zuweisen.
Beachten Sie, dass im Befehl keine ON-Klausel vorhanden ist:
mysql> GRANT 'main_read_only' TO 'reader_1'@'localhost', 'reader_2'@'localhost', 'reader_3'@'localhost';
Query OK, 0 rows affected (0.13 sec)mysql> GRANT 'main_read_write' TO 'reader_writer'@'localhost';
Query OK, 0 rows affected (0.16 sec)mysql> GRANT 'main_changer', 'main_read_only' TO 'changer_1'@'localhost';
Query OK, 0 rows affected (0.13 sec)Es kann weniger verwirrend sein, wenn Sie eine Art 'Namenskonvention verwenden ' bei der Einrichtung von Rollennamen (ich weiß nicht, ob MySQL derzeit einen bereitstellt ... Community?), und sei es aus keinem anderen Grund, als zwischen ihnen und regulären 'Nicht-Rollen'-Benutzern visuell zu unterscheiden.
Es gibt noch einiges zu tun
Das war supereinfach, nicht wahr?
Weniger überflüssig als der alte Weg der Berechtigungszuweisung.
Lassen Sie diese Benutzer jetzt arbeiten.
Wir können die gewährten Privilegien für einen Benutzer mit der SHOW GRANTS-Syntax sehen. Folgendes ist derzeit dem Benutzerkonto reader_1 zugewiesen:
mysql> SHOW GRANTS FOR 'reader_1'@'localhost';
+------------------------------------------------------+
| Grants for [email protected] |
+------------------------------------------------------+
| GRANT USAGE ON *.* TO `reader_1`@`localhost` |
| GRANT `main_read_only`@`%` TO `reader_1`@`localhost` |
+------------------------------------------------------+
2 rows in set (0.02 sec)Obwohl dies eine informative Ausgabe liefert, können Sie 'tunen ' die Anweisung für noch detailliertere Informationen über alle genauen Berechtigungen, die eine zugewiesene Rolle bereitstellt, indem Sie eine USING-Klausel in die SHOW GRANTS-Anweisung aufnehmen und den Namen der zugewiesenen Rolle benennen:
mysql> SHOW GRANTS FOR 'reader_1'@'localhost' USING 'main_read_only';
+-------------------------------------------------------------+
| Grants for [email protected] |
+-------------------------------------------------------------+
| GRANT USAGE ON *.* TO `reader_1`@`localhost` |
| GRANT SELECT ON `practice`.`name` TO `reader_1`@`localhost` |
| GRANT `main_read_only`@`%` TO `reader_1`@`localhost` |
+-------------------------------------------------------------+
3 rows in set (0.00 sec)Nach dem Einloggen mit reader_1:
mysql> SELECT * FROM practice.name;
ERROR 1142 (42000): SELECT command denied to user 'reader_1'@'localhost' for table 'name'Was in aller Welt? Diesem Benutzer wurden über die Rolle main_read_only SELECT-Berechtigungen gewährt.
Schauen wir uns zur Untersuchung zwei neue Tabellen in Version 8 an, speziell für Rollen.
Die Tabelle mysql.role_edges zeigt, welche Rollen Benutzern zugewiesen wurden:
mysql> SELECT * FROM mysql.role_edges;
+-----------+-----------------+-----------+---------------+-------------------+
| FROM_HOST | FROM_USER | TO_HOST | TO_USER | WITH_ADMIN_OPTION |
+-----------+-----------------+-----------+---------------+-------------------+
| % | main_changer | localhost | changer_1 | N |
| % | main_read_only | localhost | changer_1 | N |
| % | main_read_only | localhost | reader_1 | N |
| % | main_read_only | localhost | reader_2 | N |
| % | main_read_only | localhost | reader_3 | N |
| % | main_read_write | localhost | reader_writer | N |
+-----------+-----------------+-----------+---------------+-------------------+
6 rows in set (0.00 sec)Aber ich denke, die andere zusätzliche Tabelle, mysql.default_roles, wird uns besser helfen, die SELECT-Probleme für Benutzer reader_1 zu lösen:
mysql> DESC mysql.default_roles;
+-------------------+----------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+-------------------+----------+------+-----+---------+-------+
| HOST | char(60) | NO | PRI | | |
| USER | char(32) | NO | PRI | | |
| DEFAULT_ROLE_HOST | char(60) | NO | PRI | % | |
| DEFAULT_ROLE_USER | char(32) | NO | PRI | | |
+-------------------+----------+------+-----+---------+-------+
4 rows in set (0.00 sec)mysql> SELECT * FROM mysql.default_roles;
Empty set (0.00 sec)Leerer Ergebnissatz.
Es stellt sich heraus, damit ein Benutzer eine Rolle und letztendlich die Privilegien verwenden kann, muss dem Benutzer eine Standardrolle zugewiesen werden.
mysql> SET DEFAULT ROLE main_read_only TO 'reader_1'@'localhost', 'reader_2'@'localhost', 'reader_3'@'localhost';
Query OK, 0 rows affected (0.11 sec)(Eine Standardrolle kann mehreren Benutzern in einem Befehl wie oben zugewiesen werden …)
mysql> SET DEFAULT ROLE main_read_only, main_changer TO 'changer_1'@'localhost';
Query OK, 0 rows affected (0.10 sec)(Ein Benutzer kann mehrere Standardrollen haben, wie im Fall von Benutzer changer_1…)
Benutzer reader_1 ist jetzt eingeloggt...
mysql> SELECT CURRENT_USER();
+--------------------+
| CURRENT_USER() |
+--------------------+
| [email protected] |
+--------------------+
1 row in set (0.00 sec)mysql> SELECT CURRENT_ROLE();
+----------------------+
| CURRENT_ROLE() |
+----------------------+
| `main_read_only`@`%` |
+----------------------+
1 row in set (0.03 sec)Wir können die derzeit aktive Rolle sehen und auch, dass reader_1 jetzt SELECT-Befehle ausgeben kann:
mysql> SELECT * FROM practice.name;
+--------+------------+
| f_name | l_name |
+--------+------------+
| Jim | Dandy |
| Johhny | Applesauce |
| Ashley | Zerro |
| Ashton | Zerra |
| Ashmon | Zerro |
+--------+------------+
5 rows in set (0.00 sec)Andere versteckte Nuancen
Es gibt noch einen weiteren wichtigen Teil des Puzzles wir müssen verstehen.
Es gibt möglicherweise 3 verschiedene „Ebenen“ oder „Varianten“ der Rollenzuweisung:
SET ROLE …;
SET DEFAULT ROLE …;
SET ROLE DEFAULT …;Ich werde dem Benutzer reader_1 eine zusätzliche Rolle GEWÄHREN und mich dann mit diesem Benutzer anmelden (nicht gezeigt):
mysql> GRANT 'main_read_write' TO 'reader_1'@'localhost';
Query OK, 0 rows affected (0.17 sec)Da die Rolle main_read_write das INSERT-Privileg hat, kann Benutzer reader_1 diesen Befehl jetzt ausführen, richtig?
mysql> INSERT INTO name(f_name, l_name)
-> VALUES('Josh', 'Otwell');
ERROR 1142 (42000): INSERT command denied to user 'reader_1'@'localhost' for table 'name'Was geht hier vor?
Das kann helfen...
mysql> SELECT CURRENT_ROLE();
+----------------------+
| CURRENT_ROLE() |
+----------------------+
| `main_read_only`@`%` |
+----------------------+
1 row in set (0.00 sec)Zur Erinnerung:Wir haben dem Benutzer reader_1 zunächst die Standardrolle main_read_only zugewiesen. Hier müssen wir eine dieser unterschiedlichen „Ebenen“ dessen verwenden, was ich locker ausgedrückt bezeichne 'Rolleneinstellung':
mysql> SET ROLE main_read_write;
Query OK, 0 rows affected (0.00 sec)mysql> SELECT CURRENT_ROLE();
+-----------------------+
| CURRENT_ROLE() |
+-----------------------+
| `main_read_write`@`%` |
+-----------------------+
1 row in set (0.00 sec)Versuchen Sie nun erneut, diesen INSERT:
mysql> INSERT INTO name(f_name, l_name)
-> VALUES('Josh', 'Otwell');
Query OK, 1 row affected (0.12 sec)Sobald sich der Benutzer reader_1 jedoch wieder abmeldet, ist die Rolle main_read_write nicht mehr aktiv, wenn sich reader_1 wieder anmeldet. Obwohl dem Benutzer reader_1 die Rolle main_read_write zugewiesen wurde, ist dies nicht die Standardrolle.
Lernen wir nun die 3. „Ebene“ der „Rolleneinstellung“ kennen, SET ROLE DEFAULT.
Angenommen, Benutzer reader_1 hat noch keine Rollen zugewiesen:
mysql> SHOW GRANTS FOR 'reader_1'@'localhost';
+----------------------------------------------+
| Grants for [email protected] |
+----------------------------------------------+
| GRANT USAGE ON *.* TO `reader_1`@`localhost` |
+----------------------------------------------+
1 row in set (0.00 sec)Lassen Sie uns diesem Benutzer 2 Rollen GEWÄHREN:
mysql> GRANT 'main_changer', 'main_read_write' TO 'reader_1'@'localhost';
Query OK, 0 rows affected (0.07 sec)Weisen Sie eine Standardrolle zu:
mysql> SET DEFAULT ROLE ‘main_changer’ TO 'reader_1'@'localhost';
Query OK, 0 rows affected (0.17 sec)Dann ist bei angemeldetem Benutzer reader_1 diese Standardrolle aktiv:
mysql> SELECT CURRENT_ROLE();
+--------------------+
| CURRENT_ROLE() |
+--------------------+
| `main_changer`@`%` |
+--------------------+
1 row in set (0.00 sec)Wechseln Sie nun zur Rolle main_read_write:
mysql> SET ROLE 'main_read_write';
Query OK, 0 rows affected (0.01 sec)mysql> SELECT CURRENT_ROLE();
+-----------------------+
| CURRENT_ROLE() |
+-----------------------+
| `main_read_write`@`%` |
+-----------------------+
1 row in set (0.00 sec)Um jedoch zur zugewiesenen Standardrolle zurückzukehren, verwenden Sie SET ROLE DEFAULT wie unten gezeigt:
mysql> SET ROLE DEFAULT;
Query OK, 0 rows affected (0.00 sec)mysql> SELECT CURRENT_ROLE();
+--------------------+
| CURRENT_ROLE() |
+--------------------+
| `main_changer`@`%` |
+--------------------+
1 row in set (0.00 sec)Rollen nicht gewährt
Obwohl Benutzer changer_1 während einer Sitzung 2 Rollen zur Verfügung hat:
mysql> SELECT CURRENT_ROLE();
+-----------------------------------------+
| CURRENT_ROLE() |
+-----------------------------------------+
| `main_changer`@`%`,`main_read_only`@`%` |
+-----------------------------------------+
1 row in set (0.00 sec)Was passiert, wenn Sie versuchen, einem Benutzer eine Rolle zuzuweisen, die ihm nicht gewährt wurde?
mysql> SET ROLE main_read_write;
ERROR 3530 (HY000): `main_read_write`@`%` is not granted to `changer_1`@`localhost`Abgelehnt.
Zum Mitnehmen
Kein Benutzerverwaltungssystem wäre vollständig ohne die Möglichkeit, den Zugriff auf bestimmte Vorgänge bei Bedarf einzuschränken oder sogar zu entfernen.
Uns steht der SQL REVOKE-Befehl zur Verfügung, um Berechtigungen von Benutzern und Rollen zu entfernen.
Erinnern Sie sich, dass die Rolle main_changer diese Rechte hat, im Grunde haben alle Benutzer, denen diese Rolle zugeteilt wurde, dies auch:
mysql> SHOW GRANTS FOR main_changer;
+-----------------------------------------------------------------+
| Grants for [email protected]% |
+-----------------------------------------------------------------+
| GRANT USAGE ON *.* TO `main_changer`@`%` |
| GRANT UPDATE, DELETE ON `practice`.`name` TO `main_changer`@`%` |
+-----------------------------------------------------------------+
2 rows in set (0.00 sec)mysql> REVOKE DELETE ON practice.name FROM 'main_changer';
Query OK, 0 rows affected (0.11 sec)mysql> SHOW GRANTS FOR main_changer;
+---------------------------------------------------------+
| Grants for [email protected]% |
+---------------------------------------------------------+
| GRANT USAGE ON *.* TO `main_changer`@`%` |
| GRANT UPDATE ON `practice`.`name` TO `main_changer`@`%` |
+---------------------------------------------------------+
2 rows in set (0.00 sec)Um zu erfahren, welche Benutzer von dieser Änderung betroffen sind, können wir die Tabelle mysql.role_edges erneut aufrufen:
mysql> SELECT * FROM mysql.role_edges WHERE FROM_USER = 'main_changer';
+-----------+--------------+-----------+-----------+-------------------+
| FROM_HOST | FROM_USER | TO_HOST | TO_USER | WITH_ADMIN_OPTION |
+-----------+--------------+-----------+-----------+-------------------+
| % | main_changer | localhost | changer_1 | N |
+-----------+--------------+-----------+-----------+-------------------+
1 row in set (0.00 sec)Und wir können sehen, dass Benutzer changer_1 nicht länger das DELETE-Privileg hat:
mysql> SHOW GRANTS FOR 'changer_1'@'localhost' USING 'main_changer';
+--------------------------------------------------------------------------+
| Grants for [email protected] |
+--------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO `changer_1`@`localhost` |
| GRANT UPDATE ON `practice`.`name` TO `changer_1`@`localhost` |
| GRANT `main_changer`@`%`,`main_read_only`@`%` TO `changer_1`@`localhost` |
+--------------------------------------------------------------------------+
3 rows in set (0.00 sec)Wenn wir schließlich eine Rolle vollständig loswerden müssen, haben wir dafür den DROP ROLE-Befehl:
mysql> DROP ROLE main_read_only;
Query OK, 0 rows affected (0.17 sec)Und beim Abfragen der Tabelle mysql.role_edges wurde die Rolle main_read_only entfernt:
mysql> SELECT * FROM mysql.role_edges;
+-----------+-----------------+-----------+---------------+-------------------+
| FROM_HOST | FROM_USER | TO_HOST | TO_USER | WITH_ADMIN_OPTION |
+-----------+-----------------+-----------+---------------+-------------------+
| % | main_changer | localhost | changer_1 | N |
| % | main_read_write | localhost | reader_1 | N |
| % | main_read_write | localhost | reader_writer | N |
+-----------+-----------------+-----------+---------------+-------------------+
3 rows in set (0.00 sec)(Bonus:Dieses fantastische YouTube-Video war eine großartige Lernressource für mich zum Thema Rollen.)
Dieses Beispiel der Benutzererstellung, Rollenzuweisung und Einrichtung ist bestenfalls rudimentär. Rollen haben jedoch ihre eigenen Regeln, die sie alles andere als trivial machen. Ich hoffe, dass ich durch diesen Blog-Beitrag Licht in jene Bereiche geworfen habe, die weniger intuitiv sind als andere, und es den Lesern ermöglicht, die potenzielle Verwendung von Rollen in ihren Systemen besser zu verstehen.
Danke fürs Lesen.
