डेमाबेस बनाम स्कीमा पर USER के लिए DEFAULT PRIVILEGES का प्रबंधन कैसे करें?

Question

मैं SQLite3 से PostgreSQL 9.3 के लिए एक काफी सरल, आंतरिक, डेटाबेस संचालित एप्लिकेशन को माइग्रेट करना चाहता हूं और डीबी में अनुमतियों को कसता हूं क्योंकि मैं जाता हूं।

वर्तमान में डेटा को अपडेट करने के लिए एप्लिकेशन में एक कमांड शामिल है; और एक यह क्वेरी करने के लिए। स्वाभाविक रूप से, मुझे डेटाबेस को अन्य तरीकों से बनाए रखने की आवश्यकता होगी (नई तालिकाएं, विचार, ट्रिगर, आदि बनाएं)।

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

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

यहाँ मैंने जो अभी तक कोशिश की है ( psql'पोस्टग्रैज' के रूप में):

CREATE DATABASE hostdb;
REVOKE ALL ON DATABASE hostdb FROM public;
\connect hostdb
CREATE SCHEMA hostdb;
CREATE USER hostdb_admin WITH PASSWORD 'youwish';
CREATE USER hostdb_mgr   WITH PASSWORD 'youwish2';
CREATE USER hostdb_usr WITH PASSWORD 'youwish3';

GRANT ALL PRIVILEGES ON DATABASE hostdb TO hostdb_admin;
GRANT CONNECT ON DATABASE hostdb TO hostdb_mgr, hostdb_usr;
ALTER DEFAULT PRIVILEGES IN SCHEMA hostdb GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES TO hostdb_mgr;
ALTER DEFAULT PRIVILEGES IN SCHEMA hostdb GRANT SELECT ON TABLES TO hostdb_usr;

लेकिन मुझे अभीष्ट शब्दार्थ नहीं मिल रहे हैं। मैं इसे कॉन्फ़िगर करना चाहता हूं ताकि केवल hostdb_adminटेबल बना सकें (और ड्रॉप और बदल सकें); hostdb_mgr, पढ़ डालने, अद्यतन और डिफ़ॉल्ट रूप से सभी टेबल पर हटा सकते हैं; और hostdb_usrकेवल सभी तालिकाओं (और विचारों) को पढ़ सकते हैं।

जब मैंने यह कोशिश की तो मैंने पाया कि मैं hostdbइनमें से किसी भी उपयोगकर्ता के रूप में टेबल बनाने में सक्षम था ; लेकिन, प्रत्येक उपयोगकर्ता के लिए, मैं केवल उस उपयोगकर्ता द्वारा बनाई गई तालिकाओं को पढ़ या संशोधित कर सकता था - जब तक कि मैं एक स्पष्ट उपयोग नहीं करता GRANT।

मुझे लग रहा है कि कुछ CREATE DATABASEऔर के बीच में कुछ गायब है CREATE SCHEMA, को लागू SCHEMAकरने के लिए DATABASE?

(जैसा कि चीजें और अधिक उन्नत होती हैं, मेरे पास प्रश्न भी इसी तरह के प्रतिबंधों TRIGGERS, संग्रहीत प्रक्रियाओं VIEWSऔर शायद अन्य वस्तुओं पर लागू करने के लिए होंगे )।

मुझे इस पर एक सभ्य गाइड, ट्यूटोरियल या वीडियो श्रृंखला कहां मिल सकती है?

Comments

मुझे लगता है (कम से कम एक हिस्सा) आपकी समस्या publicछद्म के साथ है । इसे एक भूमिका के रूप में माना जा सकता है कि हर दूसरी भूमिका (उपयोगकर्ता, समूह - ये सभी समान हैं) का एक सदस्य है। उदाहरण के लिए, इससे विशेषाधिकार हटाने की कोशिश करें REVOKE CREATE ON SCHEMA hostdb FROM public। डेटाबेस स्तर पर अधिकारों को रद्द करना, जैसा कि आपने किया था, केवल कुछ डेटाबेस-स्तर की अनुमतियों को अक्षम करता है, स्कीमा या तालिकाओं पर कोई प्रभाव नहीं पड़ता है।

— dezso

@dezso: स्कीमा के लिए डिफ़ॉल्ट विशेषाधिकारों के विषय में गलत धारणा हो सकती है। केवल डिफ़ॉल्ट स्कीमा publicहोता है सह के लिए विशेषाधिकारों के साथ आते हैं PUBLIC। इसके अलावा, नए स्कीमा के लिए कोई डिफ़ॉल्ट विशेषाधिकार नहीं हैं । इसलिए यह प्रदर्शन उपयोग मामले को प्रभावित नहीं करता है। मेरे उत्तर में अध्याय देखें।

— एरविन ब्रान्डसेट्टर

Answer 1

मुझे इस पर एक सभ्य गाइड, ट्यूटोरियल या वीडियो श्रृंखला कहां मिल सकती है?

आपको मैनुअल में सब कुछ मिलेगा । नीचे दिए गए लिंक
दी, मामला मामूली और कभी-कभी भ्रामक नहीं है। यहाँ उपयोग के मामले के लिए एक नुस्खा है:

विधि

मैं इसे कॉन्फ़िगर करना चाहता हूं ताकि केवल hostdb_adminटेबल बना सकें (और ड्रॉप और बदल सकें); , पढ़ डालने, अद्यतन और डिफ़ॉल्ट रूप से सभी टेबल पर हटा सकते हैं; और केवल सभी तालिकाओं (और विचारों) को पढ़ सकते हैं।
hostdb_mgr
hostdb_usr

सुपरसुसर के रूप में postgres:

CREATE USER schma_admin WITH PASSWORD 'youwish';
-- CREATE USER schma_admin WITH PASSWORD 'youwish' CREATEDB CREATEROLE; -- see below
CREATE USER schma_mgr   WITH PASSWORD 'youwish2';
CREATE USER schma_usr   WITH PASSWORD 'youwish3';

यदि आप अधिक शक्तिशाली व्यवस्थापक चाहते हैं जो डेटाबेस और भूमिकाएँ भी प्रबंधित कर सकते हैं, तो भूमिका विशेषताएँ CREATEDBऔरCREATEROLE ऊपर जोड़ें ।

प्रत्येक भूमिका को अगले उच्च स्तर तक पहुँचाएँ, इसलिए सभी स्तर "निचले स्तर" से कम से कम विशेषाधिकारों के सेट को "इनहेरिट" करें (कोडिंग):

GRANT schma_usr TO schma_mgr;
GRANT schma_mgr TO schma_admin;

CREATE DATABASE hostdb;
REVOKE ALL ON DATABASE hostdb FROM public;  -- see notes below!

GRANT CONNECT ON DATABASE hostdb TO schma_usr;  -- others inherit

\connect hostdb  -- psql syntax

मैं स्कीमा का नामकरण कर रहा हूं schma( hostdbजो भ्रमित नहीं होगा)। कोई भी नाम उठाओ। वैकल्पिक रूपschma_admin से स्कीमा का स्वामी बनाएं :

CREATE SCHEMA schma AUTHORIZATION schma_admin;

SET search_path = schma;  -- see notes

ALTER ROLE schma_admin IN DATABASE hostdb SET search_path = schma; -- not inherited
ALTER ROLE schma_mgr   IN DATABASE hostdb SET search_path = schma;
ALTER ROLE schma_usr   IN DATABASE hostdb SET search_path = schma;

GRANT USAGE  ON SCHEMA schma TO schma_usr;
GRANT CREATE ON SCHEMA schma TO schma_admin;

ALTER DEFAULT PRIVILEGES FOR ROLE schma_admin
GRANT SELECT                           ON TABLES TO schma_usr;  -- only read

ALTER DEFAULT PRIVILEGES FOR ROLE schma_admin
GRANT INSERT, UPDATE, DELETE, TRUNCATE ON TABLES TO schma_mgr;  -- + write, TRUNCATE optional

ALTER DEFAULT PRIVILEGES FOR ROLE schma_admin
GRANT USAGE, SELECT, UPDATE ON SEQUENCES TO schma_mgr;  -- SELECT, UPDATE are optional 

के लिए and drop and alterनीचे दिए गए नोट।

जैसे-जैसे चीजें और अधिक उन्नत होती जाती हैं, मेरे पास उसी तरह के प्रतिबंध TRIGGERS, संग्रहीत प्रक्रियाओं VIEWSऔर शायद अन्य वस्तुओं को लागू करने के लिए प्रश्न होंगे ।

दृश्य विशेष हैं। एक के लिए:

... (लेकिन ध्यान दें कि ALL TABLESइसमें विचार और विदेशी तालिकाओं को शामिल किया गया है)।

और अद्यतन दृश्य के लिए :

ध्यान दें कि व्यू पर इन्सर्ट, अपडेट या डिलीट करने वाले यूज़र के पास व्यू पर संबंधित इंसर्ट, अपडेट या डिलीट करने की सुविधा होनी चाहिए। इसके अलावा, दृश्य के मालिक के अंतर्निहित आधार संबंधों पर संबंधित विशेषाधिकार होने चाहिए, लेकिन अद्यतन करने वाले उपयोगकर्ता को अंतर्निहित आधार संबंधों पर किसी भी अनुमति की आवश्यकता नहीं है (देखें धारा 38.5 )।

ट्रिगर भी खास हैं। आपको TRIGGERमेज पर विशेषाधिकार की आवश्यकता है , और:

• PostgreSQL 8.4 में ट्रिगर फ़ंक्शन को निष्पादित करने के लिए आवश्यक विशेषाधिकार क्या हैं?

लेकिन हम पहले से ही इस सवाल का दायरा बढ़ा रहे हैं ...

महत्वपूर्ण लेख

स्वामित्व

यदि आप schma_adminतालिकाओं को छोड़ने और बदलने के लिए (अकेले) अनुमति देना चाहते हैं, तो भूमिका को सभी वस्तुओं को अपना बनाएं । दस्तावेज़ीकरण:

किसी वस्तु को गिराने, या किसी भी तरह से अपनी परिभाषा को बदलने का अधिकार, एक अनुदान योग्य विशेषाधिकार के रूप में नहीं माना जाता है; यह मालिक में अंतर्निहित है, और इसे प्रदान या निरस्त नहीं किया जा सकता है। (हालांकि, वस्तु के मालिक की भूमिका में सदस्यता देने या रद्द करने से एक समान प्रभाव प्राप्त किया जा सकता है; नीचे देखें।) मालिक के पास वस्तु के लिए सभी अनुदान विकल्प भी हैं।

ALTER TABLE some_tbl OWNER TO schma_admin;

याschma_admin शुरू करने केलिए भूमिका के साथ सभी ऑब्जेक्ट बनाएं, फिर आपको मालिक को स्पष्ट रूप से सेट करने की आवश्यकता नहीं है। यह डिफ़ॉल्ट विशेषाधिकारों को भी सरल करता है, जिन्हें आपको केवल एक भूमिका के लिए निर्धारित करना होता है:

पहले से मौजूद वस्तु

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

• संबंध के लिए अनुमति से इनकार <तालिका>

यदि आप एक ऐसी भूमिका के साथ ऑब्जेक्ट बनाते हैं जो DEFAULT PRIVILEGESसेट नहीं होती है, तो सुपरयुसर की तरह postgres। के स्वामित्व पुनः सौंपने schma_adminऔर मैन्युअल रूप से विशेषाधिकार सेट - या सेट DEFAULT PRIVILEGESके लिए postgresके रूप में अच्छी तरह से: (जबकि सही डीबी से जुड़ा!)

ALTER DEFAULT PRIVILEGES FOR ROLE postgres GRANT ...  -- etc.

डिफ़ॉल्ट विशेषाधिकार

आपको ALTER DEFAULT PRIVILEGESकमांड का एक महत्वपूर्ण पहलू याद आ रहा था। यह वर्तमान भूमिका पर लागू होता है जब तक कि अन्यथा निर्दिष्ट न हो:

• डिफ़ॉल्ट विशेषाधिकारों को बदल नहीं सकते

डिफ़ॉल्ट विशेषाधिकार केवल वर्तमान डेटाबेस पर लागू होते हैं। तो आप डीबी क्लस्टर में अन्य डेटाबेस के साथ गड़बड़ नहीं है। दस्तावेज़ीकरण:

वर्तमान डेटाबेस में बनाई गई सभी वस्तुओं के लिए

आप कर सकते हैं भी के लिए डिफ़ॉल्ट विशेषाधिकार सेट करना चाहते हैं FUNCTIONSऔर TYPES(न केवल TABLESऔर SEQUENCES), लेकिन उन की जरूरत नहीं हो सकती है।

के लिए डिफ़ॉल्ट विशेषाधिकार PUBLIC

डिफ़ॉल्ट विशेषाधिकार विशेष रूप से PUBLICअल्पविकसित और कुछ से कम करके आंका जाता है। दस्तावेज़ीकरण:

PostgreSQL वस्तुओं के कुछ प्रकारों पर डिफ़ॉल्ट विशेषाधिकार प्रदान करता है PUBLIC। तालिका, कॉलम, स्कीमा या टेबलस्पेस पर डिफ़ॉल्ट रूप से कोई विशेषाधिकार प्रदान नहीं किए जाते हैं PUBLIC। अन्य प्रकारों के लिए, दिए गए डिफ़ॉल्ट विशेषाधिकार PUBLICइस प्रकार हैं: CONNECTऔर CREATE TEMP TABLEडेटाबेस के लिए; EXECUTEकार्यों के लिए विशेषाधिकार; और USAGE भाषाओं के लिए विशेषाधिकार।

बोल्ड जोर मेरा। आमतौर पर ऊपर दिया गया एक कमांड सब कुछ कवर करने के लिए पर्याप्त है:

REVOKE ALL ON DATABASE hostdb FROM public;

विशेष रूप से, PUBLICनए स्कीमा के लिए कोई डिफ़ॉल्ट विशेषाधिकार प्रदान नहीं किए जाते हैं । यह भ्रामक हो सकता है कि "सार्वजनिक" नाम का डिफ़ॉल्ट स्कीमा ALLविशेषाधिकारों के लिए शुरू होता है PUBLIC। नव निर्मित डेटाबेस के साथ शुरुआत को आसान बनाने के लिए यह सिर्फ एक सुविधा है। यह किसी भी तरह से अन्य स्कीमा को प्रभावित नहीं करता है। आप टेम्पलेट डेटाबेस में इन विशेषाधिकारों को रद्द कर सकते हैंtemplate1 , फिर इस क्लस्टर में सभी नए बनाए गए डेटाबेस उनके बिना शुरू होते हैं:

\connect template1
REVOKE ALL ON SCHEMA public FROM public;

फ़ायदा TEMP

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

GRANT TEMP ON DATABASE hostdb TO schma_mgr;

search_path

सेट करने के लिए मत भूलना search_path। यदि आपको क्लस्टर में केवल एक डेटाबेस मिला है तो आप केवल वैश्विक डिफ़ॉल्ट सेट कर सकते हैं postgresql.conf। अधिक (अधिक संभावना) इसे डेटाबेस की संपत्ति के रूप में, या केवल शामिल भूमिकाओं या दोनों के संयोजन के लिए सेट करें। विवरण:

• कैसे खोज_पथ पहचानकर्ता संकल्प और "वर्तमान स्कीमा" को प्रभावित करता है

आप के लिए यह सेट कर सकते हैं schma, publicयदि आप के रूप में अच्छी, या यहाँ तक कि (कम संभावना है) सार्वजनिक स्कीमा का उपयोग $user, schma, public...

डिफ़ॉल्ट स्कीमा "सार्वजनिक" का उपयोग करने के लिए एक विकल्प होगा जो search_pathकि डिफ़ॉल्ट सेटिंग्स के साथ काम करना चाहिए जब तक कि आपने इसे नहीं बदला। PUBLICइस मामले में विशेषाधिकारों को रद्द करना याद रखें ।

सम्बंधित

• PostgreSQL में एक विशेष डेटाबेस के लिए विशेषाधिकार प्रदान करें
• PostgreSQL - DB उपयोगकर्ता को केवल फ़ंक्शन कॉल करने की अनुमति दी जानी चाहिए

Comments

मैं खोज रहा था कि नए बनाए गए सुपरयुसर में डिफ़ॉल्ट व्यवस्थापक निजीकृत कैसे जोड़ा जाए, इसलिए मुझे उसे हर टेबल पर जोड़-तोड़ अधिकार देने की आवश्यकता नहीं होगी। अनाम: मैं यह पाया। और thisअंतरिक्ष यान के लिए निर्देश की तरह दिखता है ...

— डेनिस माताफोनोव

@DenisMatafonov: सुपरसर्स के पास सभी विशेषाधिकार स्वतः हैं। मेरा सुझाव है कि आप अपने मामले की बारीकियों के साथ एक नया प्रश्न शुरू करें। टिप्पणियाँ जगह नहीं हैं। आप संदर्भ के लिए हमेशा संबंधित प्रश्नों / उत्तरों से लिंक कर सकते हैं।

— एरविन ब्रान्डस्टेट्टर

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

— कॉम्बिनेटरवादी