MySQL 8.0 में बदली गई भूमिकाओं का उपयोग कैसे करें

डेटाबेस सुरक्षा किसी भी MySQL सेटअप के लिए महत्वपूर्ण है। उपयोगकर्ता किसी भी प्रणाली की नींव होते हैं। डेटाबेस सिस्टम के संदर्भ में, मैं आमतौर पर उनके बारे में दो अलग-अलग समूहों में सोचता हूं:

एप्लिकेशन, सेवा, या प्रोग्राम उपयोगकर्ता - मूल रूप से ग्राहक या सेवा का उपयोग करने वाले ग्राहक।
डेटाबेस डेवलपर्स, प्रशासक, विश्लेषक, आदि… - जो डेटाबेस के बुनियादी ढांचे को बनाए रखते हैं, उसके साथ काम करते हैं या उसकी निगरानी करते हैं।

जबकि प्रत्येक उपयोगकर्ता को किसी न किसी स्तर पर डेटाबेस तक पहुँचने की आवश्यकता होती है, वे सभी अनुमतियाँ समान नहीं बनाई जाती हैं।

उदाहरण के लिए, ग्राहकों और ग्राहकों को अपने 'संबंधित उपयोगकर्ता खाते' डेटा तक पहुंच की आवश्यकता होती है, लेकिन उस पर भी कुछ स्तर के नियंत्रण के साथ निगरानी की जानी चाहिए। हालांकि, कुछ टेबल और डेटा सख्ती से ऑफ-लिमिट (जैसे, सिस्टम टेबल) होना चाहिए।

फिर भी:

विश्लेषक को 'पढ़ने की पहुंच . चाहिए ', क्वेरी टेबल के माध्यम से जानकारी और अंतर्दृष्टि प्राप्त करने के लिए…
डेवलपर्स को अपना काम करने के लिए कई अनुमतियों और विशेषाधिकारों की आवश्यकता होती है…
DBA को शो चलाने के लिए 'रूट' या समान प्रकार के विशेषाधिकारों की आवश्यकता है...
किसी सेवा के खरीदारों को अपना ऑर्डर और भुगतान इतिहास देखना होगा...

आप कल्पना कर सकते हैं (मुझे पता है कि मैं करता हूं) एक डेटाबेस पारिस्थितिकी तंत्र के भीतर कई उपयोगकर्ताओं या उपयोगकर्ताओं के समूहों को प्रबंधित करना कितना मुश्किल काम है।

MySQL के पुराने संस्करणों में, एक बहु-उपयोगकर्ता वातावरण कुछ हद तक नीरस और दोहरावदार तरीके से स्थापित किया गया है।

फिर भी, संस्करण 8 एक असाधारण, और शक्तिशाली, SQL मानक सुविधा - भूमिका - को लागू करता है जो पूरी प्रक्रिया के अधिक अनावश्यक क्षेत्रों में से एक को कम करता है:उपयोगकर्ता को विशेषाधिकार प्रदान करना।

तो, MySQL में क्या भूमिका है?

आप निश्चित रूप से 2018 में MySQL पर जा सकते हैं:8.0 में क्या है और अन्य अवलोकन, मैंने यहां कई ब्लॉग के लिए लिखा है जहां मैं उच्च-स्तरीय अवलोकन के लिए भूमिकाओं का उल्लेख करता हूं। हालाँकि, जहाँ मैंने केवल उन्हें वहाँ संक्षेप में प्रस्तुत किया था, यह वर्तमान पोस्ट गहराई तक जाने और पूरी तरह से भूमिकाओं पर ध्यान केंद्रित करने के लिए लगता है।

यहाँ बताया गया है कि कैसे ऑनलाइन MySQL दस्तावेज़ एक भूमिका को परिभाषित करता है:"एक MySQL भूमिका विशेषाधिकारों का एक नामित संग्रह है"।

क्या केवल यही परिभाषा सहायक नहीं लगती?

लेकिन कैसे?

हम निम्नलिखित उदाहरणों में देखेंगे।

प्रदान किए गए उदाहरणों को नोट करने के लिए

इस पोस्ट में शामिल उदाहरण व्यक्तिगत 'एकल-उपयोगकर्ता' विकास और शिक्षण कार्य केंद्र/वातावरण में हैं, इसलिए सुनिश्चित करें और उन सर्वोत्तम प्रथाओं को लागू करें जो आपकी विशेष आवश्यकताओं या आवश्यकताओं के लिए आपको लाभान्वित करती हैं। प्रदर्शित उपयोगकर्ता नाम और पासवर्ड विशुद्ध रूप से मनमाना और कमजोर हैं।

पिछले संस्करणों में उपयोगकर्ता और विशेषाधिकार

MySQL 5.7 में, भूमिकाएँ मौजूद नहीं हैं। उपयोगकर्ताओं को विशेषाधिकार सौंपना व्यक्तिगत रूप से किया जाता है। यह बेहतर ढंग से समझने के लिए कि भूमिकाएँ क्या प्रदान करती हैं, आइए उनका उपयोग न करें। इसका कोई मतलब नहीं है, मुझे पता है। लेकिन, जैसे-जैसे हम पोस्ट के माध्यम से आगे बढ़ेंगे, यह होगा।

नीचे हम कुछ उपयोगकर्ता बनाते हैं:

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';

फिर उन उपयोगकर्ताओं को कुछ विशेषाधिकार दिए जाते हैं:

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';

वाह, खुशी है कि खत्म हो गया है। अब वापस...

और ठीक उसी तरह, आपसे दो और 'केवल-पढ़ने के लिए' उपयोगकर्ताओं को लागू करने का अनुरोध है…

ड्रॉइंग बोर्ड पर वापस जाएं:

CREATE USER 'reader_2'@'localhost' IDENTIFIED BY 'password_2'; 
CREATE USER 'reader_3'@'localhost' IDENTIFIED BY 'password_3';

उन्हें विशेषाधिकार भी सौंपना:

GRANT SELECT ON some_db.specific_table TO 'reader_2'@'localhost';
GRANT ALL ON some_db.specific_table TO 'reader_3'@'localhost';

क्या आप देख सकते हैं कि यह कैसे कम-से-उत्पादक, दोहराव से भरा और त्रुटि-प्रवण है? लेकिन, इससे भी महत्वपूर्ण बात, क्या आपने गलती पकड़ी?

आपके लिए अच्छा है!

इन दो अतिरिक्त उपयोगकर्ताओं के लिए विशेषाधिकार प्रदान करते समय, मैं गलती से नए उपयोगकर्ता रीडर_3 को सभी विशेषाधिकार दिए गए हैं।

उफ़.

एक गलती जो कोई भी कर सकता है।

MySQL भूमिकाएं दर्ज करें

भूमिकाओं के साथ, उपरोक्त में से अधिकांश व्यवस्थित विशेषाधिकार असाइनमेंट और प्रतिनिधिमंडल कुछ हद तक सुव्यवस्थित . हो सकते हैं ।

उपयोगकर्ता निर्माण मूल रूप से वही रहता है, लेकिन यह अलग-अलग भूमिकाओं के माध्यम से विशेषाधिकार प्रदान कर रहा है:

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)

mysql.user सिस्टम तालिका को क्वेरी करते हुए, आप देख सकते हैं कि नए बनाए गए उपयोगकर्ता मौजूद हैं:

(नोट:इस सीखने/विकास के माहौल में मेरे कई उपयोगकर्ता खाते हैं और बेहतर ऑन-स्क्रीन स्पष्टता के लिए अधिकांश आउटपुट को दबा दिया है।)

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)

मेरे पास यह मनमानी तालिका और नमूना डेटा है:

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)

आइए अब नए उपयोगकर्ताओं को नाम तालिका का उपयोग करने के लिए विशेषाधिकार स्थापित करने और असाइन करने के लिए भूमिकाओं का उपयोग करें।

सबसे पहले, भूमिकाएं बनाएं:

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)

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)

इस आउटपुट के आधार पर, हम अनुमान लगा सकते हैं; कि सभी सार में, भूमिकाएं वास्तव में, स्वयं उपयोगकर्ता हैं।

अगला, विशेषाधिकार असाइनमेंट:

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)

एक संक्षिप्त अंतराल

एक मिनट रुकिए। क्या मैं सिर्फ लॉग इन कर सकता हूं और भूमिका खातों के साथ कोई कार्य स्वयं कर सकता हूं? आखिरकार, वे उपयोगकर्ता हैं और उनके पास आवश्यक विशेषाधिकार हैं।

आइए main_changer की भूमिका के साथ अभ्यास डेटाबेस में लॉग इन करने का प्रयास करें:

:~$ mysql -u main_changer -p practice
Enter password: 
ERROR 1045 (28000): Access denied for user 'main_changer'@'localhost' (using password: YES

साधारण तथ्य यह है कि हमें एक पासवर्ड संकेत के साथ प्रस्तुत किया जाता है, यह एक अच्छा संकेत है कि हम (इस समय कम से कम) नहीं कर सकते। जैसा कि आपको याद है, मैंने उनके निर्माण के दौरान किसी भी भूमिका के लिए पासवर्ड सेट नहीं किया था।

mysql.user सिस्टम टेबल्स के ऑथेंटिकेशन_स्ट्रिंग कॉलम का क्या कहना है?

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)

मैंने आईएन () विधेय जांच के लिए भूमिका नामों के बीच रूट उपयोगकर्ता को शामिल किया है ताकि यह प्रदर्शित किया जा सके कि इसमें एक प्रमाणीकरण_स्ट्रिंग है, जहां भूमिकाएं नहीं हैं।

क्रिएट रोल डॉक्यूमेंटेशन में यह मार्ग इसे अच्छी तरह से स्पष्ट करता है:"एक भूमिका जब बनाई जाती है तो लॉक हो जाती है, उसका कोई पासवर्ड नहीं होता है, और उसे डिफ़ॉल्ट प्रमाणीकरण प्लगइन सौंपा जाता है। (इन भूमिका विशेषताओं को बाद में ALTER USER स्टेटमेंट के साथ बदला जा सकता है, जिनके पास उपयोगकर्ता हैं वैश्विक उपयोगकर्ता विशेषाधिकार बनाएं।)"

मौजूदा कार्य पर वापस, अब हम उपयोगकर्ताओं को उनके विशेषाधिकारों के आवश्यक स्तर के आधार पर भूमिकाएँ सौंप सकते हैं।

नोटिस नो ON क्लॉज कमांड में मौजूद है:

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)

यदि आप किसी प्रकार की 'नामकरण परंपरा . का उपयोग करते हैं तो यह कम भ्रमित करने वाला हो सकता है ' भूमिका नाम स्थापित करते समय, (यदि MySQL इस समय एक प्रदान करता है तो मुझे पता नहीं है ... समुदाय?) यदि किसी अन्य कारण से उनके और नियमित 'गैर-भूमिका' उपयोगकर्ताओं के बीच अंतर करने के अलावा कोई अन्य कारण नहीं है।

अभी भी कुछ काम बाकी है

यह बहुत आसान था, है ना?

पुराने तरीके . से कम बेमानी विशेषाधिकार असाइनमेंट का।

आइए उन उपयोगकर्ताओं को अभी काम पर लगाएं।

हम SHOW GRANTS सिंटैक्स वाले उपयोगकर्ता के लिए दिए गए विशेषाधिकार देख सकते हैं। यहां बताया गया है कि वर्तमान में रीडर_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)

हालांकि यह एक सूचनात्मक आउटपुट प्रदान करता है, आप 'ट्यून . कर सकते हैं ' SHOW GRANTS स्टेटमेंट में USING क्लॉज को शामिल करके और असाइन की गई भूमिकाओं के नाम का नामकरण करके किसी असाइन की गई भूमिका के बारे में और भी अधिक बारीक जानकारी के लिए स्टेटमेंट:

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)

रीडर_1 के साथ लॉग इन करने के बाद:

mysql> SELECT * FROM practice.name;
ERROR 1142 (42000): SELECT command denied to user 'reader_1'@'localhost' for table 'name'

पृथ्वी पर क्या? उस उपयोगकर्ता को main_read_only भूमिका के माध्यम से चयन विशेषाधिकार दिए गए थे।

जाँच करने के लिए, आइए संस्करण 8 में 2 नई तालिकाओं पर जाएँ, विशेष रूप से भूमिकाओं के लिए।

Mysql.role_edges तालिका दिखाती है कि किसी भी उपयोगकर्ता को कौन सी भूमिकाएँ दी गई हैं:

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)

लेकिन, मुझे लगता है कि अन्य अतिरिक्त तालिका, mysql.default_roles, उपयोगकर्ता पाठक के लिए SELECT समस्याओं को हल करने में बेहतर मदद करेगी_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)

खाली परिणाम सेट।

एक भूमिका का उपयोग करने में सक्षम होने के लिए बाहर निकलता है, और अंततः विशेषाधिकार - उपयोगकर्ता को एक डिफ़ॉल्ट भूमिका सौंपी जानी चाहिए।

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)

(ऊपर के रूप में एक कमांड में एक से अधिक उपयोगकर्ताओं को एक डिफ़ॉल्ट भूमिका सौंपी जा सकती है…)

mysql> SET DEFAULT ROLE main_read_only, main_changer TO 'changer_1'@'localhost';
Query OK, 0 rows affected (0.10 sec)

(उपयोगकर्ता के पास कई डिफ़ॉल्ट भूमिकाएँ हो सकती हैं, जैसा कि उपयोगकर्ता परिवर्तक_1 के मामले में निर्दिष्ट किया गया है…)

उपयोगकर्ता रीडर_1 अब लॉग इन है...

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)

हम वर्तमान में सक्रिय भूमिका देख सकते हैं और यह भी, कि रीडर_1 अब SELECT कमांड जारी कर सकता है:

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)

अन्य छिपी हुई बारीकियां

पहेली . का एक और महत्वपूर्ण हिस्सा है हमें समझने की जरूरत है।

भूमिका असाइनमेंट के संभावित रूप से 3 अलग-अलग 'स्तर' या 'वेरिएंट' हैं:

SET ROLE …;
SET DEFAULT ROLE …;
SET ROLE DEFAULT …;

मैं उपयोगकर्ता रीडर_1 को एक अतिरिक्त भूमिका प्रदान करूंगा और फिर उस उपयोगकर्ता के साथ लॉगिन करूंगा (दिखाया नहीं गया):

mysql> GRANT 'main_read_write' TO 'reader_1'@'localhost';
Query OK, 0 rows affected (0.17 sec)

चूंकि भूमिका main_read_write में INSERT विशेषाधिकार है, उपयोगकर्ता रीडर_1 अब उस आदेश को सही तरीके से चला सकता है?

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'

यहाँ क्या हो रहा है?

यह मदद कर सकता है...

mysql> SELECT CURRENT_ROLE();
+----------------------+
| CURRENT_ROLE()       |
+----------------------+
| `main_read_only`@`%` |
+----------------------+
1 row in set (0.00 sec)

याद रखें, हमने शुरुआत में उपयोगकर्ता रीडर_1 को main_read_only की डिफ़ॉल्ट भूमिका निर्धारित की थी। यह वह जगह है जहां हमें उन विशिष्ट 'स्तरों' में से एक का उपयोग करने की आवश्यकता है जो मैं ढीला शब्द हूं 'भूमिका निर्धारण':

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)

अब उस INSERT को पुन:प्रयास करें:

mysql> INSERT INTO name(f_name, l_name)
    -> VALUES('Josh', 'Otwell');
Query OK, 1 row affected (0.12 sec)

हालांकि, एक बार जब उपयोगकर्ता रीडर_1 वापस लॉग आउट हो जाता है, तो रीडर_1 के वापस लॉग इन करने पर भूमिका main_read_write अब सक्रिय नहीं होगी। हालांकि उपयोगकर्ता रीडर_1 को main_read_write भूमिका दी गई है, यह डिफ़ॉल्ट नहीं है।

आइए अब 'भूमिका निर्धारण' के तीसरे 'स्तर' के बारे में जानते हैं, SET ROLE DEFAULT।

मान लें कि उपयोगकर्ता पाठक_1 को अभी तक कोई भूमिका सौंपी नहीं गई है:

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)

आइए इस उपयोगकर्ता को 2 भूमिकाएँ प्रदान करें:

mysql> GRANT 'main_changer', 'main_read_write' TO 'reader_1'@'localhost';
Query OK, 0 rows affected (0.07 sec)

एक डिफ़ॉल्ट भूमिका असाइन करें:

mysql> SET DEFAULT ROLE ‘main_changer’ TO 'reader_1'@'localhost';
Query OK, 0 rows affected (0.17 sec)

फिर उपयोगकर्ता रीडर_1 के लॉग इन होने पर, वह डिफ़ॉल्ट भूमिका सक्रिय होती है:

mysql> SELECT CURRENT_ROLE();
+--------------------+
| CURRENT_ROLE()     |
+--------------------+
| `main_changer`@`%` |
+--------------------+
1 row in set (0.00 sec)

अब भूमिका 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)

लेकिन, असाइन की गई डिफ़ॉल्ट भूमिका पर वापस लौटने के लिए, SET ROLE DEFAULT का उपयोग करें जैसा कि नीचे दिखाया गया है:

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)

भूमिकाएं प्रदान नहीं की गई हैं

भले ही उपयोगकर्ता परिवर्तक_1 की एक सत्र के दौरान 2 भूमिकाएँ उपलब्ध हों:

mysql> SELECT CURRENT_ROLE();
+-----------------------------------------+
| CURRENT_ROLE()                          |
+-----------------------------------------+
| `main_changer`@`%`,`main_read_only`@`%` |
+-----------------------------------------+
1 row in set (0.00 sec)

यदि आप किसी उपयोगकर्ता को उस भूमिका के लिए प्रयास करते हैं और सेट करते हैं जो उन्हें प्रदान नहीं की गई है तो क्या होगा?

mysql> SET ROLE main_read_write;
ERROR 3530 (HY000): `main_read_write`@`%` is not granted to `changer_1`@`localhost`

अस्वीकृत।

टेकथ अवे

कोई भी उपयोगकर्ता प्रबंधन प्रणाली आवश्यकता पड़ने पर कुछ कार्यों तक पहुंच को बाधित या हटाने की क्षमता के बिना पूर्ण नहीं होगी।

उपयोगकर्ताओं और भूमिकाओं से विशेषाधिकारों को हटाने के लिए हमारे पास SQL REVOKE कमांड है।

याद रखें कि भूमिका main_changer के पास विशेषाधिकारों का यह सेट है, अनिवार्य रूप से, उन सभी उपयोगकर्ताओं को यह भूमिका दी गई है:

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)

यह जानने के लिए कि इस परिवर्तन ने किन उपयोगकर्ताओं को प्रभावित किया है, हम फिर से 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)

और हम देख सकते हैं कि उपयोगकर्ता परिवर्तक_1 के पास अब DELETE विशेषाधिकार नहीं है:

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)

अंत में, अगर हमें किसी भूमिका से पूरी तरह छुटकारा पाना है, तो उसके लिए हमारे पास DROP ROLE कमांड है:

mysql> DROP ROLE main_read_only;
Query OK, 0 rows affected (0.17 sec)

और mysql.role_edges तालिका को क्वेरी करते हुए, main_read_only भूमिका हटा दी गई है:

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)

(बोनस:यह शानदार YouTube वीडियो मेरे लिए रोल्स पर सीखने का एक बेहतरीन संसाधन था।)

उपयोगकर्ता निर्माण, भूमिका असाइनमेंट और सेटअप का यह उदाहरण सबसे अच्छा प्राथमिक है। फिर भी, भूमिकाओं के अपने स्वयं के नियम होते हैं जो उन्हें तुच्छ से दूर करते हैं। मेरी आशा है कि इस ब्लॉग पोस्ट के माध्यम से, मैंने उन क्षेत्रों पर प्रकाश डाला है जो दूसरों की तुलना में कम सहज ज्ञान युक्त हैं, जिससे पाठकों को उनके सिस्टम के भीतर संभावित भूमिका उपयोग को बेहतर ढंग से समझने में मदद मिलती है।

पढ़ने के लिए धन्यवाद।