Det är alltid en huvudvärk... du måste lägga till en ny användarroll eller ändra vissa privilegier, och du måste tilldela den en... i taget en. Detta är en vanlig plikt, särskilt i stora organisationer, eller i ett företag där du har en komplex privilegiestruktur, eller till och med om du måste hantera ett stort antal databasanvändare.
Låt oss till exempel säga att du behöver lägga till UPDATE-privilegiet till en specifik databas för hela QA-teamet, om de är ett team på fem är det inga problem, men om de är 50... eller 100... bli hård. Naturligtvis kan du alltid skriva ett manus till det, men på så sätt finns det alltid risk.
I den här bloggen kommer vi att se hur vi kan lösa detta problem med databasanvändarhantering genom att använda roller och med specifika tips om hur man använder dem med MariaDB.
Vad är en roll?
I databasvärlden är en roll en grupp av privilegier som kan tilldelas en eller flera användare, och en användare kan ha en eller flera roller tilldelade sig. För att göra en jämförelse är det som en grupp på Linux OS.
Om vi ser det föregående exemplet om UPDATE-privilegiet på QA-teamet, om vi har QA-rollen skapad och alla QA-medlemmar har denna roll tilldelad, spelar det ingen roll antalet medlemmar, du behöver bara ändra privilegiet på denna QA-roll och den kommer att spridas för alla QA-användare.
Roller på MariaDB
För att hantera roller på MariaDB måste du skapa rollen med CREATE ROLE-satsen, tilldela privilegiet till den rollen med en GRANT-sats och sedan tilldela privilegiet till användaren för att kunna använda den här rollen. Du kan också ställa in en standardroll, så att användaren tar den när han ansluter.
Som databasanvändare måste du ställa in rollen när du kommer åt databasen (om det inte finns en standardroll), och du kan ändra rollen om det behövs med en SET ROLE-sats.
Från applikationssidan bör du kunna ställa in rollen (eller använda standard) innan du frågar för att få detta att fungera, så i gamla applikationer kan det vara komplicerat att implementera.
Låt oss se några specifikationer för roller på MariaDB.
- Endast en roll kan vara aktiv samtidigt för den aktuella användaren.
- Sedan MariaDB 10.1 har vi en standardroll. Den här rollen aktiveras automatiskt när användaren ansluter.
- Roller lagras i minnet.
Hur man kontrollerar roller
På MariaDB finns det flera sätt att kontrollera det:
- VISA BIDRAG [ FÖR (användare | roll) ]:Lista bidragen för den aktuella användaren eller för 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ÄLJ användare FRÅN mysql.user WHERE is_role='Y':Lista rollerna som skapats i databasen.
MariaDB [testing]> SELECT user FROM mysql.user WHERE is_role='Y'; +--------+ | user | +--------+ | qateam | +--------+ 1 row in set (0.000 sec) - VÄLJ * FRÅN information_schema.applicable_roles:Det är en lista över tillgängliga roller för den aktuella användaren.
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ÄLJ * FRÅN information_schema.enabled_roles:Lista de aktuella aktiva rollerna.
MariaDB [testing]> SELECT * FROM information_schema.enabled_roles; +-----------+ | ROLE_NAME | +-----------+ | qateam | +-----------+ 1 row in set (0.000 sec) - VÄLJ * FRÅN mysql.roles_mapping:Lista relationerna mellan roller och användartillstånd.
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)
Hur man hanterar roller på MariaDB
Låt oss se ett exempel på hur man hanterar det på MariaDB. I det här fallet kommer vi att använda MariaDB 10.3-versionen som körs på CentOS 7.
Låt oss först skapa en ny databasanvändare:
MariaDB [testing]> CREATE USER [email protected]'%' IDENTIFIED BY 'PASSWORD';Om vi kontrollerar anslagen för den här nya användaren ser vi något i stil med detta:
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)Nu ska vi försöka logga in med den här användaren och ansluta till 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 kunde se kan vi inte ansluta till testdatabasen med den här användaren, så nu skapar vi en "qateam"-roll med privilegierna och vi tilldelar den här rollen till den här nya användaren.
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)Om vi försöker använda den här rollen utan GRANT ser vi följande fel:
MariaDB [(none)]> SET ROLE qateam;
ERROR 1959 (OP000): Invalid role specification `qateam`Så nu kör vi GRANT så att användaren kan använda det:
MariaDB [(none)]> GRANT qateam TO [email protected]'%';
Query OK, 0 rows affected (0.000 sec)Ställ in rollen till den aktuella användaren:
MariaDB [(none)]> SET ROLE qateam;
Query OK, 0 rows affected (0.000 sec)Och försök komma åt 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 kontrollera bidragen för den aktuella användaren:
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)Och den nuvarande rollen:
MariaDB [testing]> SELECT CURRENT_ROLE;
+--------------+
| CURRENT_ROLE |
+--------------+
| qateam |
+--------------+
1 row in set (0.000 sec)Här kan vi se tillståndet för qateam-rollen, och det är det, vi har inte privilegiet tilldelat direkt till användaren, vi har privilegierna för rollen, och användaren tar privilegierna därifrån.
Slutsats
Att hantera roller kan göra vårt liv enklare i stora företag eller databaser med ett stort antal användare som har tillgång till det. Om vi vill använda det från vår applikation måste vi ta hänsyn till att applikationen måste kunna hantera den också.