Bảo mật cơ sở dữ liệu rất quan trọng đối với bất kỳ thiết lập MySQL nào. Người dùng là nền tảng của bất kỳ hệ thống nào. Về hệ thống cơ sở dữ liệu, tôi thường nghĩ về chúng theo hai nhóm riêng biệt:
- Người dùng ứng dụng, dịch vụ hoặc chương trình - về cơ bản là khách hàng hoặc khách hàng đang sử dụng dịch vụ.
- Nhà phát triển cơ sở dữ liệu, quản trị viên, nhà phân tích, v.v.… - Những người duy trì, làm việc với hoặc giám sát cơ sở hạ tầng cơ sở dữ liệu.
Mặc dù mỗi người dùng cần truy cập cơ sở dữ liệu ở một số cấp độ, nhưng không phải tất cả các quyền đó đều được tạo ra như nhau.
Ví dụ:khách hàng và khách hàng cần quyền truy cập vào dữ liệu 'tài khoản người dùng có liên quan' của họ, nhưng ngay cả điều đó cũng cần được giám sát với một số cấp độ kiểm soát. Tuy nhiên, một số bảng và dữ liệu phải nằm ngoài giới hạn nghiêm ngặt (ví dụ:bảng hệ thống).
Tuy nhiên:
- Nhà phân tích cần ' quyền truy cập đọc ', để thu thập thông tin và cái nhìn sâu sắc qua các bảng truy vấn…
- Các nhà phát triển yêu cầu nhiều quyền và đặc quyền để thực hiện công việc của họ…
- DBA cần có đặc quyền 'root' hoặc loại tương tự để chạy chương trình…
- Người mua dịch vụ cần xem lịch sử đặt hàng và thanh toán của họ…
Bạn có thể tưởng tượng (tôi biết là tôi làm) một nhiệm vụ quản lý nhiều người dùng hoặc nhóm người dùng trong hệ sinh thái cơ sở dữ liệu khó khăn như thế nào.
Trong các phiên bản MySQL cũ hơn, môi trường nhiều người dùng được thiết lập theo cách hơi đơn điệu và lặp đi lặp lại.
Tuy nhiên, phiên bản 8 triển khai một tính năng tiêu chuẩn SQL đặc biệt và mạnh mẽ - Vai trò - giúp giảm bớt một trong những khu vực dư thừa hơn của toàn bộ quy trình:gán đặc quyền cho người dùng.
Vậy, vai trò trong MySQL là gì?
Bạn chắc chắn có thể truy cập, MySQL vào năm 2018:Có gì trong 8.0 và Các quan sát khác, tôi đã viết cho blog Somenines tại đây, nơi tôi đề cập đến các vai trò để có cái nhìn tổng quan cấp cao. Tuy nhiên, tôi chỉ tóm tắt chúng ở đó, bài đăng hiện tại này có vẻ sẽ đi sâu hơn và chỉ tập trung vào các vai trò.
Đây là cách tài liệu MySQL trực tuyến định nghĩa một vai trò:"Một vai trò MySQL là một tập hợp các đặc quyền được đặt tên".
Chỉ riêng định nghĩa đó thôi có vẻ hữu ích không?
Nhưng bằng cách nào?
Chúng ta sẽ thấy trong các ví dụ sau.
Để ghi lại các ví dụ được cung cấp
Các ví dụ có trong bài đăng này nằm trong môi trường / máy trạm học tập và phát triển 'một người dùng' cá nhân, vì vậy hãy đảm bảo và thực hiện các phương pháp hay nhất đó có lợi cho bạn cho các nhu cầu hoặc yêu cầu cụ thể của bạn. Tên người dùng và mật khẩu được trình bày hoàn toàn là tùy ý và yếu.
Người dùng và Đặc quyền trong các Phiên bản Trước
Trong MySQL 5.7, các vai trò không tồn tại. Việc gán đặc quyền cho người dùng được thực hiện riêng lẻ. Để hiểu rõ hơn những gì vai trò cung cấp, chúng ta hãy không sử dụng chúng. Điều đó không có ý nghĩa gì cả, tôi biết. Tuy nhiên, khi chúng ta xem xét bài đăng, nó sẽ xảy ra.
Dưới đây chúng tôi tạo một số người dùng:
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';
Sau đó, những người dùng đó được cấp một số đặc quyền:
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';
Chà, vui vì điều đó đã qua. Bây giờ trở lại…
Và như vậy, bạn có yêu cầu triển khai thêm hai người dùng 'chỉ đọc'…
Quay lại bảng vẽ:
CREATE USER 'reader_2'@'localhost' IDENTIFIED BY 'password_2';
CREATE USER 'reader_3'@'localhost' IDENTIFIED BY 'password_3';
Cũng chỉ định cho họ các đặc quyền:
GRANT SELECT ON some_db.specific_table TO 'reader_2'@'localhost';
GRANT ALL ON some_db.specific_table TO 'reader_3'@'localhost';
Bạn có thể thấy cách này kém hiệu quả hơn, đầy sự lặp lại và dễ xảy ra lỗi như thế nào không? Nhưng, quan trọng hơn, bạn có mắc sai lầm không?
Tốt cho bạn!
Trong khi cấp đặc quyền cho hai người dùng bổ sung này, tôi vô tình đã cấp TẤT CẢ đặc quyền cho người đọc người dùng mới_3.
Rất tiếc.
Một sai lầm mà bất kỳ ai cũng có thể mắc phải.
Nhập vai trò của MySQL
Với các vai trò, phần lớn có hệ thống ở trên phân công và ủy quyền đặc quyền có thể được sắp xếp hợp lý .
Việc tạo người dùng về cơ bản vẫn giống nhau, nhưng nó chỉ định các đặc quyền thông qua các vai trò khác nhau:
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)
Truy vấn bảng hệ thống mysql.user, bạn có thể thấy những người dùng mới được tạo đó tồn tại:
(Lưu ý:Tôi có một số tài khoản người dùng trong môi trường học tập / phát triển này và đã loại bỏ nhiều đầu ra để có độ rõ nét hơn trên màn hình.)
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)
Tôi có bảng và dữ liệu mẫu tùy ý này:
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)
Bây giờ chúng ta hãy sử dụng các vai trò để thiết lập và chỉ định, các đặc quyền cho người dùng mới sử dụng bảng tên.
Đầu tiên, hãy tạo các vai trò:
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)
Lưu ý lại bảng 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)
Dựa trên kết quả đầu ra này, chúng ta có thể phỏng đoán; rằng về bản chất, các vai trò trên thực tế, là chính người dùng.
Tiếp theo, chỉ định đặc quyền:
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)
Phần kết thúc ngắn gọn
Đợi tí. Tôi có thể chỉ đăng nhập và thực hiện bất kỳ tác vụ nào với chính tài khoản vai trò không? Sau cùng, họ là người dùng và họ có các đặc quyền cần thiết.
Hãy thử đăng nhập vào cơ sở dữ liệu thực hành với role main_changer:
:~$ mysql -u main_changer -p practice
Enter password:
ERROR 1045 (28000): Access denied for user 'main_changer'@'localhost' (using password: YES
Thực tế đơn giản rằng chúng tôi được hiển thị với một lời nhắc mật khẩu là một dấu hiệu tốt rằng chúng tôi không thể (ít nhất là tại thời điểm này). Như bạn nhớ lại, tôi đã không đặt mật khẩu cho bất kỳ vai trò nào trong quá trình tạo vai trò.
Cột verify_string của bảng hệ thống mysql.user có ý nghĩa gì?
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)
Tôi đã bao gồm người dùng gốc trong số các tên vai trò cho kiểm tra vị từ IN () để đơn giản chứng minh rằng nó có một chuỗi xác thực, trong đó các vai trò không có.
Đoạn văn này trong tài liệu CREATE ROLE giải thích rõ ràng rằng:"Vai trò khi được tạo sẽ bị khóa, không có mật khẩu và được gán plugin xác thực mặc định. (Những thuộc tính vai trò này có thể được thay đổi sau bằng câu lệnh ALTER USER, bởi những người dùng có đặc quyền TẠO NGƯỜI DÙNG toàn cầu.) "
Quay lại nhiệm vụ hiện tại, giờ đây chúng tôi có thể chỉ định vai trò cho người dùng dựa trên mức độ đặc quyền cần thiết của họ.
Lưu ý rằng không có mệnh đề ON nào trong lệnh:
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)
Có thể ít nhầm lẫn hơn nếu bạn sử dụng một số loại ' quy ước đặt tên 'khi thiết lập tên vai trò, (tôi không biết liệu MySQL có cung cấp tên vai trò tại thời điểm này hay không… Cộng đồng?) nếu không vì lý do gì khác ngoài việc phân biệt giữa chúng và những người dùng' không có vai trò 'thông thường một cách trực quan.
Vẫn còn một số việc phải làm
Điều đó thật dễ dàng phải không?
Ít dư thừa hơn so với cách cũ chỉ định đặc quyền.
Hãy để những người dùng đó hoạt động ngay bây giờ.
Chúng ta có thể thấy các đặc quyền được cấp cho người dùng với cú pháp SHOW GRANTS. Đây là những gì hiện được chỉ định cho tài khoản người dùng reader_1:
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)
Mặc dù điều đó cung cấp một đầu ra nhiều thông tin, nhưng bạn có thể ' điều chỉnh 'câu lệnh cho thông tin chi tiết hơn về bất kỳ đặc quyền chính xác nào mà một vai trò được chỉ định cung cấp bằng cách bao gồm điều khoản SỬ DỤNG trong câu lệnh SHOW GRANTS và đặt tên cho vai trò được chỉ định:
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)
Sau khi đăng nhập bằng reader_1:
mysql> SELECT * FROM practice.name;
ERROR 1142 (42000): SELECT command denied to user 'reader_1'@'localhost' for table 'name'
Những gì trên trái đất? Người dùng đó đã được cấp đặc quyền SELECT thông qua vai trò main_read_only.
Để điều tra, hãy truy cập 2 bảng mới trong phiên bản 8, đặc biệt cho các vai trò.
Bảng mysql.role_edges hiển thị những vai trò nào đã được cấp cho bất kỳ người dùng nào:
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)
Tuy nhiên, tôi cảm thấy bảng bổ sung khác, mysql.default_roles, sẽ giúp chúng tôi giải quyết vấn đề CHỌN tốt hơn cho người đọc người dùng_1:
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)
Đã đặt kết quả trống.
Hóa ra, để người dùng có thể sử dụng một vai trò - và cuối cùng là các đặc quyền - thì người dùng phải được chỉ định một vai trò mặc định.
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)
(Một vai trò mặc định có thể được gán cho nhiều người dùng trong một lệnh như trên…)
mysql> SET DEFAULT ROLE main_read_only, main_changer TO 'changer_1'@'localhost';
Query OK, 0 rows affected (0.10 sec)
(Một người dùng có thể có nhiều vai trò mặc định được chỉ định như trong trường hợp cho trình thay đổi người dùng_1…)
User reader_1 hiện đã đăng nhập ...
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)
Chúng tôi có thể thấy vai trò hiện đang hoạt động và người đọc_1 đó cũng có thể đưa ra lệnh CHỌN ngay bây giờ:
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)
Các sắc thái tiềm ẩn khác
Có một phần quan trọng khác của câu đố chúng ta cần hiểu.
Có thể có 3 'cấp độ' hoặc 'biến thể' khác nhau của việc phân công vai trò:
SET ROLE …;
SET DEFAULT ROLE …;
SET ROLE DEFAULT …;
Tôi sẽ CẤP một vai trò bổ sung cho người đọc người dùng_1 và sau đó đăng nhập với người dùng đó (không hiển thị):
mysql> GRANT 'main_read_write' TO 'reader_1'@'localhost';
Query OK, 0 rows affected (0.17 sec)
Vì role main_read_write không có đặc quyền INSERT, người dùng reader_1 hiện có thể chạy lệnh đó đúng không?
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'
Điều gì đang xảy ra ở đây?
Điều này có thể giúp ...
mysql> SELECT CURRENT_ROLE();
+----------------------+
| CURRENT_ROLE() |
+----------------------+
| `main_read_only`@`%` |
+----------------------+
1 row in set (0.00 sec)
Nhắc lại, ban đầu chúng tôi đặt trình đọc người dùng_1 một vai trò mặc định của main_read_only. Đây là nơi chúng ta cần sử dụng một trong những 'cấp độ' khác biệt đó của những gì tôi thuật ngữ lỏng lẻo 'thiết lập vai trò':
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)
Bây giờ hãy thử INSERT lại:
mysql> INSERT INTO name(f_name, l_name)
-> VALUES('Josh', 'Otwell');
Query OK, 1 row affected (0.12 sec)
Tuy nhiên, khi người dùng reader_1 đăng xuất lại, vai trò main_read_write sẽ không còn hoạt động khi reader_1 đăng nhập lại. Mặc dù người dùng reader_1 có cấp vai trò main_read_write cho nó, nhưng nó không phải là vai trò mặc định.
Bây giờ chúng ta hãy cùng tìm hiểu "cấp độ" thứ 3 của "thiết lập vai trò", ĐẶT VAI TRÒ.
Giả sử user reader_1 chưa có vai trò nào được chỉ định:
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)
Hãy CẤP cho người dùng này 2 vai trò:
mysql> GRANT 'main_changer', 'main_read_write' TO 'reader_1'@'localhost';
Query OK, 0 rows affected (0.07 sec)
Chỉ định một vai trò mặc định:
mysql> SET DEFAULT ROLE ‘main_changer’ TO 'reader_1'@'localhost';
Query OK, 0 rows affected (0.17 sec)
Sau đó, với user reader_1 đã đăng nhập, vai trò mặc định đó sẽ hoạt động:
mysql> SELECT CURRENT_ROLE();
+--------------------+
| CURRENT_ROLE() |
+--------------------+
| `main_changer`@`%` |
+--------------------+
1 row in set (0.00 sec)
Bây giờ chuyển sang vai trò 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)
Tuy nhiên, để quay lại vai trò mặc định được chỉ định, hãy sử dụng ĐẶT VAI TRÒ VAI TRÒ như được hiển thị bên dưới:
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)
Vai trò không được cấp
Mặc dù trình thay đổi người dùng_1 có sẵn 2 vai trò trong một phiên:
mysql> SELECT CURRENT_ROLE();
+-----------------------------------------+
| CURRENT_ROLE() |
+-----------------------------------------+
| `main_changer`@`%`,`main_read_only`@`%` |
+-----------------------------------------+
1 row in set (0.00 sec)
Điều gì sẽ xảy ra nếu bạn cố gắng và đặt người dùng vào một vai trò mà họ chưa được cấp?
mysql> SET ROLE main_read_write;
ERROR 3530 (HY000): `main_read_write`@`%` is not granted to `changer_1`@`localhost`
Bị từ chối.
Taketh Away
Sẽ không có hệ thống quản lý người dùng nào hoàn chỉnh nếu không có khả năng hạn chế hoặc thậm chí loại bỏ quyền truy cập vào các hoạt động nhất định nếu có nhu cầu.
Chúng tôi sử dụng lệnh SQL REVOKE để xóa các đặc quyền khỏi người dùng và vai trò.
Nhớ lại rằng vai trò main_changer có tập hợp các đặc quyền này, về cơ bản, tất cả những người dùng được cấp vai trò này cũng làm như vậy:
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)
Để biết những người dùng nào mà thay đổi này ảnh hưởng, chúng ta có thể truy cập lại vào bảng mysql.role_edges:
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)
Và chúng tôi có thể thấy rằng người thay đổi_1 không còn có đặc quyền XÓA:
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)
Cuối cùng, nếu chúng ta cần loại bỏ hoàn toàn một vai trò, chúng ta có lệnh DROP ROLE cho việc đó:
mysql> DROP ROLE main_read_only;
Query OK, 0 rows affected (0.17 sec)
Và truy vấn bảng mysql.role_edges, role main_read_only đã bị xóa:
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)
(Phần thưởng:Video YouTube tuyệt vời này là một tài nguyên học tập tuyệt vời đối với tôi về Vai trò.)
Ví dụ này về tạo người dùng, phân công vai trò và thiết lập là tốt nhất. Tuy nhiên, các vai trò có bộ quy tắc riêng khiến chúng trở nên tầm thường. Hy vọng của tôi là thông qua bài đăng trên blog này, tôi đã làm sáng tỏ những lĩnh vực kém trực quan hơn những lĩnh vực khác, giúp người đọc hiểu rõ hơn về việc sử dụng vai trò tiềm năng trong hệ thống của họ.
Cảm ơn bạn đã đọc.