Det er altid en hovedpine... du skal tilføje en ny brugerrolle eller ændre nogle privilegier, og du skal tildele den én... efter... én. Dette er en almindelig pligt, især i store organisationer, eller i en virksomhed, hvor du har en kompleks privilegiestruktur, eller endda hvis du skal administrere et stort antal databasebrugere.
Lad os f.eks. sige, at du skal tilføje UPDATE-privilegiet til en specifik database for hele QA-teamet, hvis de er et hold på fem, er der ikke noget problem, men hvis de er 50... eller 100... blive hårdt. Man kan selvfølgelig altid skrive et manuskript til det, men på denne måde er der altid risiko.
I denne blog vil vi se, hvordan vi kan løse dette databasebrugerstyringsproblem ved at bruge roller og med specifikke tips til, hvordan man bruger dem med MariaDB.
Hvad er en rolle?
I databaseverdenen er en rolle en gruppe af privilegier, der kan tildeles en eller flere brugere, og en bruger kan have en eller flere roller tildelt sig. For at lave en sammenligning er det som en gruppe på Linux OS.
Hvis vi ser det forrige eksempel om UPDATE-privilegiet på QA-teamet, hvis vi har QA-rollen oprettet, og alle QA-medlemmerne har denne rolle tildelt, er det lige meget antallet af medlemmer, du skal kun ændre privilegiet på denne QA-rolle, og den vil blive udbredt til alle QA-brugere.
Roller på MariaDB
For at administrere roller på MariaDB skal du oprette rollen med CREATE ROLE-sætningen, tildele privilegiet til denne rolle med en GRANT-sætning og derefter tildele privilegiet til brugeren for at kunne bruge denne rolle. Du kan også indstille en standardrolle, så brugeren tager den, når der oprettes forbindelse.
Som databasebruger skal du indstille rollen, når du tilgår databasen (hvis der ikke er en standardrolle), og du kan om nødvendigt ændre rollen med en SET ROLE-sætning.
Fra applikationssiden bør du være i stand til at indstille rollen (eller bruge standarden), før du forespørger for at få dette til at fungere, så i gamle applikationer kan det være komplekst at implementere.
Lad os se nogle specifikationer for roller på MariaDB.
- Kun én rolle kan være aktiv på samme tid for den aktuelle bruger.
- Siden MariaDB 10.1 har vi en standardrolle. Denne rolle aktiveres automatisk, når brugeren opretter forbindelse.
- Roller er gemt i hukommelsen.
Sådan tjekker du roller
På MariaDB er der flere måder at kontrollere det på:
- VIS TILSKUD [ FOR (bruger | rolle) ]:Liste bevillingerne for den aktuelle bruger eller for en specifik.
MariaDB [testing]> SHOW GRANTS for [email protected]'%'; +----------------------------------------------------------------------------------------------------------+ | Grants for [email protected]% | +----------------------------------------------------------------------------------------------------------+ | GRANT USAGE ON *.* TO 'testuser'@'%' IDENTIFIED BY PASSWORD '*FAAFFE644E901CFAFAEC7562415E5FAEC243B8B2' | +----------------------------------------------------------------------------------------------------------+ 1 row in set (0.000 sec) - VÆLG bruger FRA mysql.user WHERE is_role='Y':List de roller, der er oprettet i databasen.
MariaDB [testing]> SELECT user FROM mysql.user WHERE is_role='Y'; +--------+ | user | +--------+ | qateam | +--------+ 1 row in set (0.000 sec) - VÆLG * FRA information_schema.applicable_roles:Det er en liste over tilgængelige roller for den aktuelle bruger.
MariaDB [testing]> SELECT * FROM information_schema.applicable_roles; +-------------+-----------+--------------+------------+ | GRANTEE | ROLE_NAME | IS_GRANTABLE | IS_DEFAULT | +-------------+-----------+--------------+------------+ | [email protected]% | qateam | NO | NO | +-------------+-----------+--------------+------------+ 1 row in set (0.000 sec) - VÆLG * FRA information_schema.enabled_roles:List de aktuelle aktive roller.
MariaDB [testing]> SELECT * FROM information_schema.enabled_roles; +-----------+ | ROLE_NAME | +-----------+ | qateam | +-----------+ 1 row in set (0.000 sec) - VÆLG * FRA mysql.roles_mapping:Liste relationerne mellem roller og brugerbevillinger.
MariaDB [testing]> SELECT * FROM mysql.roles_mapping; +-----------+-----------+--------+--------------+ | Host | User | Role | Admin_option | +-----------+-----------+--------+--------------+ | localhost | root | qateam | Y | | % | testuser | qateam | N | +-----------+-----------+--------+--------------+ 2 rows in set (0.000 sec)
Sådan administrerer du roller på MariaDB
Lad os se et eksempel på, hvordan man administrerer det på MariaDB. I dette tilfælde bruger vi MariaDB 10.3-versionen, der kører på CentOS 7.
Lad os først oprette en ny databasebruger:
MariaDB [testing]> CREATE USER [email protected]'%' IDENTIFIED BY 'PASSWORD';Hvis vi tjekker bevillingerne for denne nye bruger, vil vi se noget som dette:
MariaDB [testing]> SHOW GRANTS for [email protected]'%';
+----------------------------------------------------------------------------------------------------------+
| Grants for [email protected]% |
+----------------------------------------------------------------------------------------------------------+
| GRANT USAGE ON *.* TO 'testuser'@'%' IDENTIFIED BY PASSWORD '*FAAFFE644E901CFAFAEC7562415E5FAEC243B8B2' |
+----------------------------------------------------------------------------------------------------------+
1 row in set (0.000 sec)Lad os nu prøve at logge ind med denne bruger og oprette forbindelse til testdatabasen:
$ mysql -utestuser -p
Enter password:
Welcome to the MariaDB monitor. Commands end with ; or \g.
Your MariaDB connection id is 54
Server version: 10.3.16-MariaDB-log MariaDB Server
Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.MariaDB [(none)]> use testing
ERROR 1044 (42000): Access denied for user 'testuser'@'%' to database 'testing'Som vi kunne se, kan vi ikke oprette forbindelse til testdatabasen med denne bruger, så nu opretter vi en "qateam"-rolle med privilegierne, og vi tildeler denne rolle til denne nye bruger.
MariaDB [testing]> CREATE ROLE qateam;
Query OK, 0 rows affected (0.001 sec)MariaDB [testing]> GRANT SELECT,INSERT,UPDATE,DELETE ON testing.* TO qateam;
Query OK, 0 rows affected (0.000 sec)Hvis vi forsøger at bruge denne rolle uden GRANT, vil vi se følgende fejl:
MariaDB [(none)]> SET ROLE qateam;
ERROR 1959 (OP000): Invalid role specification `qateam`Så nu kører vi GRANT for at tillade brugeren at bruge det:
MariaDB [(none)]> GRANT qateam TO [email protected]'%';
Query OK, 0 rows affected (0.000 sec)Indstil rollen til den aktuelle bruger:
MariaDB [(none)]> SET ROLE qateam;
Query OK, 0 rows affected (0.000 sec)Og prøv at få adgang til databasen:
MariaDB [(none)]> use testing;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
MariaDB [testing]>Vi kan tjekke bevillingerne for den nuværende bruger:
MariaDB [(none)]> SHOW GRANTS for [email protected]'%';
+----------------------------------------------------------------------------------------------------------+
| Grants for [email protected]% |
+----------------------------------------------------------------------------------------------------------+
| GRANT qateam TO 'testuser'@'%' |
| GRANT USAGE ON *.* TO 'testuser'@'%' IDENTIFIED BY PASSWORD '*FAAFFE644E901CFAFAEC7562415E5FAEC243B8B2' |
+----------------------------------------------------------------------------------------------------------+
2 rows in set (0.000 sec)Og den nuværende rolle:
MariaDB [testing]> SELECT CURRENT_ROLE;
+--------------+
| CURRENT_ROLE |
+--------------+
| qateam |
+--------------+
1 row in set (0.000 sec)Her kan vi se bevillingen til qateam-rollen, og det er det, vi har ikke privilegiet tildelt direkte til brugeren, vi har privilegierne til rollen, og brugeren tager privilegierne derfra.
Konklusion
At administrere roller kan gøre vores liv lettere i store virksomheder eller databaser med et stort antal brugere, der har adgang til det. Hvis vi vil bruge det fra vores applikation, skal vi tage højde for, at applikationen også skal kunne administrere den.