PostgreSQL विशेषाधिकार और उपयोगकर्ता प्रबंधन - आपको क्या पता होना चाहिए

PostgreSQL के भीतर उपयोगकर्ता प्रबंधन मुश्किल हो सकता है। आम तौर पर नए उपयोगकर्ताओं को पर्यावरण में कुछ प्रमुख क्षेत्रों के भीतर, संगीत कार्यक्रम में प्रबंधित किया जाता है। अक्सर, विशेषाधिकार एक मोर्चे पर सही होते हैं, फिर भी दूसरे पर गलत तरीके से कॉन्फ़िगर किए जाते हैं। यह ब्लॉग पोस्ट उपयोगकर्ता या भूमिका के लिए व्यावहारिक 'टिप्स एंड ट्रिक्स' प्रदान करेगा, जैसा कि हम इसे जानते हैं, PostgreSQL के भीतर सेटअप।

जिन विषय क्षेत्रों पर हम ध्यान केंद्रित करेंगे वे हैं:

• पोस्टग्रेएसक्यूएल की टेक ऑन रोल्स

आप भूमिकाओं, भूमिका विशेषताओं, अपनी भूमिकाओं के नामकरण के लिए सर्वोत्तम प्रथाओं और सामान्य भूमिका सेटअप के बारे में जानेंगे।

• pg_hba.conf फ़ाइल

इस खंड में हम क्लाइंट-साइड कनेक्शन और सर्वर के साथ संचार के लिए एक प्रमुख फाइल और उसकी सेटिंग्स को देखेंगे।

• डेटाबेस, टेबल और कॉलम स्तर के विशेषाधिकार और प्रतिबंध।

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

PostgreSQL की भूमिकाएँ - 'भूमिका' क्या है और इसे कैसे बनाएँ?

PostgreSQL के भीतर डेटाबेस एक्सेस के लिए अनुमतियों को एक भूमिका की अवधारणा के साथ नियंत्रित किया जाता है, जो एक उपयोगकर्ता के समान है। भूमिकाएं PostgreSQL पारिस्थितिकी तंत्र में भी उपयोगकर्ताओं के समूहों का प्रतिनिधित्व कर सकती हैं।

PostgreSQL भूमिकाओं के लिए उन डेटाबेस ऑब्जेक्ट्स को विशेषाधिकार प्रदान करने की क्षमता स्थापित करता है, जो उन ऑब्जेक्ट्स तक पहुंच और क्रियाओं को सक्षम करते हैं। भूमिकाओं में किसी अन्य भूमिका के लिए सदस्यता प्रदान करने की क्षमता होती है। अनुमत क्लाइंट प्रमाणीकरण के लिए विशेषताएँ अनुकूलन विकल्प प्रदान करती हैं।

CREATE ROLE कमांड के माध्यम से भूमिकाओं के लिए विशेषताएँ, आधिकारिक PostgreSQL दस्तावेज़ीकरण में उपलब्ध हैं।

नीचे, वे विशेषताएं दी गई हैं जिन्हें आप नई भूमिका सेट करते समय आमतौर पर असाइन करेंगे। इनमें से अधिकांश स्व-व्याख्यात्मक हैं। हालांकि, उदाहरण के उपयोग के साथ किसी भी भ्रम को दूर करने के लिए एक संक्षिप्त विवरण प्रदान किया गया है।

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

CREATEDB - भूमिका को डेटाबेस बनाने की अनुमति देता है।

CREATEROLE - इस विशेषता के साथ, एक भूमिका CREATE ROLE कमांड जारी कर सकती है। इसलिए, अन्य भूमिकाएँ बनाएँ।

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

कुछ विशेषताओं में एक स्पष्ट ध्रुवीय विपरीत नाम का कमांड होता है और जब अनिर्दिष्ट छोड़ दिया जाता है तो आमतौर पर डिफ़ॉल्ट होता है।

उदा.
सुपरयूज़र | NOSUPERUSER
CREATEROLE |NOCREATEROLE
LOGIN |NOLOGIN

आइए इनमें से कुछ विशेषताओं को विभिन्न कॉन्फ़िगरेशन के लिए क्रियान्वित करें जिन्हें आप आगे बढ़ने के लिए सेट अप कर सकते हैं।

भूमिकाएं बनाना और छोड़ना

भूमिका बनाना अपेक्षाकृत सरल है। यहां एक त्वरित उदाहरण दिया गया है:

postgres=# CREATE ROLE $money_man;
ERROR: syntax error at or near "$"
LINE 1: CREATE ROLE $money_man;

वहां क्या गलत हुआ? पता चला, भूमिका नाम एक अक्षर के अलावा किसी और चीज़ से शुरू नहीं हो सकते।

"नाम को दोहरे उद्धरण चिह्नों में लपेटने के बारे में क्या?" आइए देखें:

postgres=# CREATE ROLE "$money_man";
CREATE ROLE

यह काम किया, हालांकि शायद एक अच्छा विचार नहीं है। नाम के बीच में एक विशेष चरित्र कैसा रहेगा?

postgres=# CREATE ROLE money$_man;
CREATE ROLE

वहां कोई समस्या नहीं है। दोहरे उद्धरण चिह्नों के बिना भी, कोई त्रुटि नहीं लौटाई गई।

मुझे किसी उपयोगकर्ता के लिए $money_man की नाम संरचना पसंद नहीं है। मैं आपको $money_man छोड़ रहा हूं और नए सिरे से शुरुआत कर रहा हूं। DROP ROLE कमांड किसी भूमिका को हटाने का ध्यान रखता है। यहाँ यह प्रयोग में है।

postgres=# DROP ROLE $money_man;
ERROR: syntax error at or near "$"
LINE 1: DROP ROLE $money_man;

और $money_man भूमिका के साथ एक और त्रुटि। दोबारा, दोहरे उद्धरण चिह्नों का सहारा लेना यह है।

postgres=# DROP ROLE "$money_man";
DROP ROLE

लॉगिन विशेषाधिकार

आइए दो अलग-अलग उपयोगकर्ताओं को देखें, एक LOGIN विशेषाधिकार के साथ और दूसरा बिना। मैं उन्हें पासवर्ड भी दूंगा।

postgres=# CREATE ROLE nolog_user WITH PASSWORD 'pass1';
CREATE ROLE

postgres=# CREATE ROLE log_user WITH LOGIN PASSWORD 'pass2';
CREATE ROLE

नोट:उपरोक्त काल्पनिक भूमिकाओं के लिए प्रदान किए गए पासवर्ड केवल प्रदर्शन उद्देश्यों के लिए हैं। भूमिकाओं को लागू करते समय आपको हमेशा अद्वितीय और कठोर पासवर्ड प्रदान करने का प्रयास करना चाहिए। जबकि एक पासवर्ड बिना पासवर्ड के बेहतर है, एक कठोर पासवर्ड एक छोटे से पासवर्ड से भी बेहतर है।

आइए log_user को CREATEDB और CREATEROLE विशेषताएँ ALTER ROLE कमांड के साथ असाइन करें।

postgres=# ALTER ROLE log_user CREATEROLE CREATEDB;
ALTER ROLE

आप pg_role कैटलॉग की जाँच करके इन सेट विशेषताओं को सत्यापित कर सकते हैं। रुचि के दो स्तंभ हैं rolcreaterole और rolcreatedb. दोनों बूलियन डेटा प्रकार के हैं, इसलिए इन विशेषताओं के लिए उन्हें सही के लिए t पर सेट किया जाना चाहिए।

इसी तरह की SELECT क्वेरी से पुष्टि करें।

postgres=# SELECT rolcreaterole, rolcreatedb FROM pg_roles WHERE rolname = 'log_user';
rolcreaterole | rolcreatedb 
---------------+-------------
t | t
(1 row)

आप डेटाबेस में मौजूद मौजूदा भूमिकाओं का निर्धारण कैसे कर सकते हैं?

दो उपलब्ध तरीके हैं psql \du कमांड या pg_roles कैटलॉग से चयन करना।

यहाँ वे दोनों उपयोग में हैं।

postgres=> \du
List of roles
Role name | Attributes | Member of 
------------+------------------------------------------------------------+-----------
log_user | Create role, Create DB | {}
nolog_user | Cannot login | {}

postgres=> SELECT rolname FROM pg_roles;
rolname 
----------------------
nolog_user
log_user
(2 rows)

लॉग इन करना

आइए दोनों भूमिकाओं को सर्वर में लॉगिन करने का अवसर दें।

psql -U nolog_user -W postgres
Password for user nolog_user: 
psql: FATAL: no pg_hba.conf entry for host "[local]", user "nolog_user", database "postgres", SSL off
psql -U log_user -W postgres
Password for user log_user: 
psql: FATAL: no pg_hba.conf entry for host "[local]", user "log_user", database "postgres", SSL off

इस समस्या को हल करने के लिए, हमें उस pg_hba.conf फ़ाइल को खोदना होगा। समाधान पर चर्चा की गई है क्योंकि हम इस पोस्ट में उस विशिष्ट खंड में जारी रखते हैं।

कार्रवाई योग्य उपाय

• CREATE ROLE और इसके समकक्ष, DROP ROLE, भूमिकाओं को लागू करने और हटाने के लिए आपके जाने-माने आदेश हैं।
• ALTER ROLE किसी भूमिका की विशेषताओं को बदलने का काम संभालता है।
• डेटाबेस क्लस्टर स्तर पर परिभाषा के कारण सभी डेटाबेस में भूमिकाएं मान्य हैं।
• ध्यान रखें, एक विशेष चरित्र से शुरू होने वाले भूमिका नाम बनाने के लिए, आपको इसे दोहरे उद्धरण चिह्नों के साथ 'एड्रेस' करना होगा।
• भूमिकाएं और उनके विशेषाधिकार विशेषताओं का उपयोग करके स्थापित किए जाते हैं।
• डिफ़ॉल्ट रूप से LOGIN विशेषता की आवश्यकता वाली भूमिकाएँ स्थापित करने के लिए, CREATE USER आपके निपटान में एक वैकल्पिक कमांड है। CREATE ROLE role_name LOGIN के स्थान पर प्रयुक्त, वे अनिवार्य रूप से समान हैं।

pg_hba.conf फ़ाइल - सर्वर और क्लाइंट के बीच साझा आधार स्थापित करना

एक ब्लॉग पोस्ट में pg_hba.conf फ़ाइल के सभी पहलुओं और सेटिंग्स को कवर करना सबसे अच्छा होगा। इसके बजाय, यह खंड आपके सामने आने वाली सामान्य समस्याओं और उनके समाधान के लिए समाधान प्रस्तुत करेगा।

सफल कनेक्शन के लिए समग्र रूप से दोनों भागों से संयुक्त प्रयास की आवश्यकता होती है। सर्वर से कनेक्ट होने वाली भूमिकाएं, pg_hba.conf फ़ाइल में सेटिंग पास करने के बाद भी, डेटाबेस स्तर पर सेट एक्सेस प्रतिबंधों को पूरा करना चाहिए।

जैसे-जैसे यह खंड आगे बढ़ता है, इस संबंध के प्रासंगिक उदाहरण शामिल किए जाते हैं।

अपनी pg_hba.conf फ़ाइल का पता लगाने के लिए, pg_settings VIEW पर समान चयन क्वेरी जारी करें। इस दृश्य को क्वेरी करने के लिए आपको एक सुपरयूज़र के रूप में लॉग इन होना चाहिए।

postgres=# SELECT name, setting
FROM pg_settings WHERE name LIKE '%hba%';
name | setting 
----------+-------------------------------------
hba_file | /etc/postgresql/10/main/pg_hba.conf
(1 row)

pg_hba.conf फ़ाइल में दिए गए कनेक्शन अनुरोध के लिए सात उपलब्ध स्वरूपों में से एक को निर्दिष्ट करने वाले रिकॉर्ड हैं। पूरा स्पेक्ट्रम यहां देखें।

इस ब्लॉग पोस्ट के प्रयोजन के लिए, हम उन सेटिंग्स को देखेंगे जिनका उपयोग आप स्थानीय परिवेश के लिए कर सकते हैं।

शायद यह सर्वर आपके निरंतर सीखने और अध्ययन के लिए है (जैसा कि मेरा है)।

मुझे विशेष ध्यान देना चाहिए कि ये सेटिंग्स एक से अधिक उपयोगकर्ताओं वाले कठोर सिस्टम के लिए इष्टतम सेटिंग्स नहीं हैं।

इस प्रकार के कनेक्शन के लिए क्षेत्र हैं:

local database user auth-method [auth-options]

उनका मतलब कहां है:

स्थानीय - यूनिक्स-डोमेन सॉकेट के साथ कनेक्शन का प्रयास किया जाता है।

डेटाबेस - इस रिकॉर्ड मिलान के लिए नामित डेटाबेस निर्दिष्ट करता है।

उपयोगकर्ता - डेटाबेस उपयोगकर्ता नाम इस रिकॉर्ड के लिए मेल खाता है। इस फ़ील्ड के लिए भी एकाधिक उपयोगकर्ताओं या सभी की अल्पविराम से अलग की गई सूची की अनुमति है।

auth-method - इसका उपयोग तब किया जाता है जब कोई कनेक्शन इस अद्वितीय रिकॉर्ड से मेल खाता है। इस क्षेत्र के लिए संभावित विकल्प हैं:

• विश्वास
• अस्वीकार करें
• स्क्रैम-शा-256
• एमडी5
• पासवर्ड
• जीएसएस
• एसएसपीआई
• पहचान
• सहकर्मी
• एलडीएपी
• त्रिज्या
• प्रमाणित
• पाम
• बीएसडी

nolog_user और log_user भूमिकाओं के लिए pg_hba.conf फ़ाइल में सेट की गई पंक्तियाँ इस तरह दिखती हैं:

local all nolog_user password
local all log_user password

नोट:चूंकि पासवर्ड स्पष्ट टेक्स्ट में भेजा जाता है, इसलिए इसका उपयोग अविश्वसनीय नेटवर्क वाले अविश्वसनीय वातावरण में नहीं किया जाना चाहिए।

आइए नीचे दी गई क्वेरी के साथ pg_hba_file_rules VIEW से तीन दिलचस्प कॉलम देखें। इस दृश्य को क्वेरी करने के लिए फिर से आपकी भूमिका को SUPERUSER विशेषता की आवश्यकता है।

postgres=# SELECT database, user_name, auth_method
postgres-# FROM pg_hba_file_rules
postgres-# WHERE CAST(user_name AS TEXT) LIKE '%log_user%';
database | user_name | auth_method 
----------+--------------+-------------
{all} | {nolog_user} | password
{all} | {log_user} | password
(2 rows)

हम pg_hba.conf फ़ाइल में पाई गई ऊपर दी गई पंक्तियों से समान जानकारी देख सकते हैं जैसा कि हम साथ की क्वेरी से देख सकते हैं। पहली नज़र में, ऐसा लगता है कि दोनों भूमिकाएँ लॉग इन कर सकती हैं।

हम परीक्षण और पुष्टि करेंगे।

psql -U nolog_user -W postgres
Password for user nolog_user: 
psql: FATAL: role "nolog_user" is not permitted to log in
psql -U log_user -W postgres
Password for user log_user: 
psql (10.1)
Type "help" for help.
postgres=>

यहां मुख्य बिंदु यह है, हालांकि nolog_user और log_user दोनों pg_hba.conf फ़ाइल के अनुसार लॉगिन करने में सक्षम हैं, केवल log_user को वास्तव में लॉगिन करने की अनुमति है।

जहां log_user ने डेटाबेस स्तर पहुंच प्रतिबंध (LOGIN विशेषता होने से) पारित किया, nolog_user ने नहीं किया।

आइए pg_hba.conf फ़ाइल में log_user की लाइन को संपादित करें और डेटाबेस का नाम बदलें जिसे इस भूमिका तक पहुँचने की अनुमति है। यहाँ परिवर्तन है, यह दर्शाता है कि log_user अब केवल परीक्षण डेटाबेस में प्रवेश कर सकता है।

local trial log_user password

आइए पहले पोस्टग्रेज डेटाबेस में लॉगिन करने का प्रयास करें, जो log_user के पास पहले सभी ध्वज के कारण एक्सेस था।

$ psql -U log_user -W postgres
Password for user log_user: 
psql: FATAL: no pg_hba.conf entry for host "[local]", user "log_user", database "postgres", SSL off

अब परीक्षण डेटाबेस के साथ log_user को

$ psql -U log_user -W trial
Password for user log_user: 
psql (10.1)
Type "help" for help.
trial=>

वहां कोई त्रुटि नहीं है और परीक्षण => संकेत वर्तमान में जुड़ा हुआ डेटाबेस दिखाता है।

एक बार कनेक्शन स्थापित हो जाने के बाद, ये सेटिंग्स सर्वर वातावरण में भी लागू होती हैं।

आइए उस पोस्टग्रेज डेटाबेस से फिर से जुड़ने का प्रयास करें:

trial=> \c postgres;
Password for user log_user: 
FATAL: no pg_hba.conf entry for host "[local]", user "log_user", database "postgres", SSL off
Previous connection kept

यहां प्रस्तुत उदाहरणों के माध्यम से, आपको अपने क्लस्टर में भूमिकाओं के लिए अनुकूलन विकल्पों के बारे में पता होना चाहिए।

नोट:अक्सर, परिवर्तनों को प्रभावी होने के लिए pg_hba.conf फ़ाइल को पुनः लोड करना आवश्यक होता है।

अपने सर्वर को पुनः लोड करने के लिए pg_ctl उपयोगिता का उपयोग करें।

सिंटैक्स होगा:

pg_ctl reload [-D datadir] [-s]

यह जानने के लिए कि आपका डेटादिर कहाँ है, आप pg_settings सिस्टम VIEW को क्वेरी कर सकते हैं, यदि नीचे दी गई समान SELECT क्वेरी के साथ एक SUPERUSER के रूप में लॉग इन किया गया है।

postgres=# SELECT setting FROM pg_settings WHERE name = 'data_directory';
           setting           
-----------------------------
 /var/lib/postgresql/10/main
(1 row)

फिर, पोस्टग्रेज़ उपयोगकर्ता (या अन्य SUPERUSER) को अपना शेल दें:

$ sudo -u postgres bash

जब तक आपने अपने $PATH में pg_ctl उपयोगिता को नहीं जोड़ा है, तब तक आपको इसे उपयोग के लिए पूरी तरह से योग्य बनाना होगा, फिर डेटादिर स्थान के साथ निष्पादित करने के लिए कमांड पास करना होगा।

यहां एक उदाहरण दिया गया है:

$ /usr/lib/postgresql/10/bin/pg_ctl reload -D /var/lib/postgresql/10/main
server signaled

आइए इसके साथ सर्वर की स्थिति जांचें:

$ /usr/lib/postgresql/10/bin/pg_ctl status -D /var/lib/postgresql/10/main
pg_ctl: server is running (PID: 1415)
/usr/lib/postgresql/10/bin/postgres "-D" "/var/lib/postgresql/10/main" "-c" "config_file=/etc/postgresql/10/main/postgresql.conf"

कार्रवाई योग्य उपाय

• भूमिकाओं को pg_hba.conf फ़ाइल और डेटाबेस स्तर पहुँच विशेषाधिकार दोनों से आवश्यकताओं को पूरा करना चाहिए।
प्रत्येक कनेक्शन अनुरोध के लिए
• pg_hba.conf फ़ाइल को ऊपर से नीचे चेक किया जाता है। फ़ाइल में आदेश महत्वपूर्ण है।

डेटाबेस, तालिका और कॉलम विशेषाधिकार और प्रतिबंध - कार्यों और जिम्मेदारियों के लिए उपयुक्त भूमिकाएं

डेटाबेस ऑब्जेक्ट्स (टेबल, व्यू, कॉलम, फ़ंक्शंस, आदि...) का उपयोग करने के लिए भूमिकाओं के लिए, उन्हें एक्सेस विशेषाधिकार दिए जाने चाहिए।

GRANT कमांड इन आवश्यक विशेषाधिकारों को परिभाषित करता है।

इसके उपयोग का सार जानने के लिए हम कुछ उदाहरणों पर विचार करेंगे।

डेटाबेस बनाना

चूँकि log_user को CREATEDB और CREATEROLE विशेषताएँ प्रदान की गई थीं, इसलिए हम इस भूमिका का उपयोग परीक्षण नामक परीक्षण डेटाबेस बनाने के लिए कर सकते हैं।

postgres=> CREATE DATABASE trial:
CREATE DATABASE

एक नई ROLE बनाने के अलावा:

postgres=> CREATE ROLE db_user WITH LOGIN PASSWORD 'scooby';
CREATE ROLE

अंत में, log_user नए परीक्षण डेटाबेस से जुड़ जाएगा:

postgres=> \c trial;
Password for user log_user: 
You are now connected to database "trial" as user "log_user".
trial=>

नोटिस को 'ट्रायल' नाम में बदल दिया गया है जो दर्शाता है कि हम उस डेटाबेस से जुड़े हुए हैं।

आइए एक नकली तालिका बनाने के लिए log_user का उपयोग करें।

trial=> CREATE TABLE another_workload(
trial(> id INTEGER,
trial(> first_name VARCHAR(20),
trial(> last_name VARCHAR(20),
trial(> sensitive_info TEXT);
CREATE TABLE

भूमिका log_user ने हाल ही में एक सहायक भूमिका बनाई है, db_user. हम चाहते हैं कि db_user के पास अन्य_वर्कलोड तालिका के लिए सीमित विशेषाधिकार हों।

निस्संदेह, इस भूमिका द्वारा संवेदनशील_इन्फो कॉलम तक नहीं पहुंचा जाना चाहिए। INSERT, UPDATE, और DELETE कमांड इस समय भी नहीं दी जानी चाहिए, जब तक कि db_user कुछ अपेक्षाओं को पूरा नहीं करता।

हालाँकि, db_user को SELECT क्वेरीज़ जारी करने की आवश्यकता है। हम अन्य_कार्यभार तालिका में इस भूमिका क्षमताओं को कैसे सीमित कर सकते हैं?

आइए पहले तालिका स्तर पर PostgreSQL GRANT कमांड डॉक्स में पाए गए सटीक सिंटैक्स की जांच करें।

GRANT { { SELECT | INSERT | UPDATE | REFERENCES } ( column_name [, ...] )
[, ...] | ALL [ PRIVILEGES ] ( column_name [, ...] ) }
ON [ TABLE ] table_name [, ...]
TO role_specification [, ...] [ WITH GRANT OPTION ]

इसके बाद, हम विशिष्ट सिंटैक्स को लागू करते हुए भूमिका db_user के लिए निर्धारित आवश्यकताओं को लागू करते हैं।

trial=> GRANT SELECT (id, first_name, last_name) ON TABLE another_workload TO db_user;
GRANT

ध्यान दें कि सेलेक्ट कीवर्ड के ठीक बाद, हमने उन कॉलमों को सूचीबद्ध किया है जिन्हें db_user एक्सेस कर सकता है। जब तक बदला नहीं जाता है, तब तक db_user को संवेदनशील_इन्फो कॉलम पर सेलेक्ट क्वेश्चन का प्रयास करना चाहिए, या उस मामले के लिए कोई अन्य कमांड, उन प्रश्नों को निष्पादित नहीं किया जाएगा।

db_user लॉग इन के साथ, हम टेबल से सभी कॉलम और रिकॉर्ड वापस करने के लिए एक SELECT क्वेरी का प्रयास करते हुए इसे अभ्यास में लाएंगे।

trial=> SELECT * FROM another_workload;
ERROR: permission denied for relation another_workload

इस क्वेरी में कॉलम संवेदनशील_इन्फो शामिल है। इसलिए, db_user को कोई रिकॉर्ड वापस नहीं किया जाता है।

लेकिन db_user स्वीकार्य कॉलम चुन सकता है

trial=> SELECT id, first_name, last_name
trial-> FROM another_workload;
id | first_name | last_name 
-----+------------+-----------
10 | John | Morris
191 | Jannis | Harper
2 | Remmy | Rosebuilt
(3 rows)

यह ठीक काम करता है।

हम INSERT, UPDATE और DELETE कमांड का भी परीक्षण करेंगे।

trial=> INSERT INTO another_workload(id,first_name,last_name,sensitive_info)
VALUES(17,'Jeremy','Stillman','key code:400Z');
ERROR: permission denied for relation another_workload

trial=> UPDATE another_workload
trial-> SET id = 101
trial-> WHERE id = 10;
ERROR: permission denied for relation another_workload

trial=> DELETE FROM another_workload
trial-> WHERE id = 2;;
ERROR: permission denied for relation another_workload

db_user को INSERT, UPDATE, या DELETE कमांड असाइन न करने से, भूमिका को उनका उपयोग करने से मना कर दिया जाता है।

उपलब्ध विकल्पों की अधिकता के साथ, आपकी भूमिका को कॉन्फ़िगर करना वस्तुतः असीमित है। आप उन्हें पूरी तरह कार्यात्मक बना सकते हैं, किसी भी आदेश को निष्पादित करने में सक्षम बना सकते हैं, या अपनी आवश्यकताओं के अनुसार सीमित कर सकते हैं।

कार्रवाई योग्य उपाय

• भूमिकाओं को GRANT कमांड के माध्यम से डेटाबेस ऑब्जेक्ट्स तक पहुँच विशेषाधिकार प्रदान किए जाते हैं।
• डेटाबेस ऑब्जेक्ट और उन ऑब्जेक्ट्स के विरुद्ध कमांड, PostgreSQL वातावरण में अत्यधिक कॉन्फ़िगर करने योग्य है।

समापन

इस ब्लॉग पोस्ट द्वारा दिए गए उदाहरणों के माध्यम से, आपको इसकी बेहतर समझ होनी चाहिए:

1. विशिष्ट विशेषताओं के साथ भूमिका बनाना।
2. क्लाइंट और सर्वर के बीच एक व्यावहारिक कनेक्शन सेट करना, भूमिकाओं को डेटाबेस में प्रवेश करने की अनुमति देना।
3. आवश्यक विशेषताओं को लागू करके डेटाबेस, तालिका और कॉलम स्तर की पहुंच के लिए व्यक्तिगत आवश्यकताओं को पूरा करने के लिए अपनी भूमिकाओं को अत्यधिक अनुकूलित करना।