वास्तव में SCHEMA का उपयोग क्या है?

Question

मैं पहली बार पोस्टग्रेज डेटाबेस बनाने की कोशिश कर रहा हूं, इसलिए यह शायद एक बेवकूफ सवाल है। मैंने डीबी की भूमिका के लिए बुनियादी रीड-ओनली अनुमतियां सौंपी हैं, जिन्हें मेरी php स्क्रिप्ट्स से डेटाबेस तक पहुंचना चाहिए, और मुझे एक जिज्ञासा है: यदि मैं निष्पादित करता हूं

GRANT some_or_all_privileges ON ALL TABLES IN SCHEMA schema TO role;

क्या किसी को भी निष्पादित करने की आवश्यकता है

GRANT USAGE ON SCHEMA schema TO role;

?

से प्रलेखन :

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

मुझे लगता है कि अगर मैं स्कीमा में निहित किसी भी डेटा का चयन या हेरफेर कर सकता हूं, तो मैं स्कीमा के किसी भी ऑब्जेक्ट तक पहुंच सकता हूं। क्या मै गलत हु? यदि नहीं, तो किसके GRANT USAGE ON SCHEMAलिए उपयोग किया जाता है? और दस्तावेज़ीकरण का क्या मतलब है "वस्तुओं की अपनी विशेषाधिकार आवश्यकताओं को भी पूरा करना"?

Answer 1

GRANTअलग-अलग वस्तुओं पर s अलग हैं। GRANTडेटाबेस पर आईएनजी GRANTस्कीमा के भीतर अधिकार नहीं रखता है। GRANTएक स्कीमा पर , आईने में अधिकार नहीं है।

यदि आपके पास SELECTकिसी तालिका से अधिकार हैं , लेकिन स्कीमा में यह देखने का अधिकार नहीं है कि इसमें समाहित है तो आप तालिका तक नहीं पहुँच सकते।

अधिकारों के परीक्षण क्रम में किए जाते हैं:

Do you have `USAGE` on the schema? 
    No:  Reject access. 
    Yes: Do you also have the appropriate rights on the table? 
        No:  Reject access. 
        Yes: Check column privileges.

आपका भ्रम इस तथ्य से उत्पन्न हो सकता है कि publicस्कीमा के पास GRANTभूमिका के सभी अधिकारों का डिफ़ॉल्ट है public, जो प्रत्येक उपयोगकर्ता / समूह का सदस्य है। इसलिए सभी के पास पहले से ही उस स्कीमा का उपयोग है।

मुहावरा:

(यह मानते हुए कि वस्तुओं की अपनी विशेषाधिकार आवश्यकताएं भी पूरी होती हैं)

यह कह रहा है कि आपके पास USAGEऑब्जेक्ट्स का उपयोग करने के लिए स्कीमा पर होना चाहिए , लेकिन स्कीमा के भीतर ऑब्जेक्ट्स का उपयोग करने के लिए USAGEस्कीमा स्वयं के लिए पर्याप्त नहीं है, आपके पास ऑब्जेक्ट्स पर अधिकार भी होने चाहिए।

यह एक डायरेक्टरी ट्री की तरह है। यदि आप इसके भीतर somedirफ़ाइल somefileके साथ एक निर्देशिका बनाते हैं, तो इसे सेट करें ताकि केवल आपका अपना उपयोगकर्ता ही निर्देशिका या फ़ाइल (फ़ाइल rwx------पर मोड rw-------, फ़ाइल पर मोड ) तक पहुंच सके , फिर कोई और उस निर्देशिका को सूचीबद्ध नहीं कर सकता है ताकि फ़ाइल मौजूद हो।

यदि आप फ़ाइल (मोड rw-r--r--) पर विश्व-पढ़ने के अधिकार देना चाहते थे, लेकिन निर्देशिका अनुमतियों को नहीं बदलते तो इससे कोई फर्क नहीं पड़ता था। फ़ाइल को पढ़ने के लिए कोई भी नहीं देख सकता था, क्योंकि उनके पास निर्देशिका को सूचीबद्ध करने के अधिकार नहीं हैं।

यदि आप इसके बजाय rwx-r-xr-xनिर्देशिका पर सेट करते हैं, तो इसे सेट करना ताकि लोग निर्देशिका को सूचीबद्ध कर सकें और फ़ाइल अनुमतियों को बदल सकें, लेकिन लोग फ़ाइल को सूचीबद्ध कर सकते हैं, लेकिन इसे पढ़ नहीं सकते क्योंकि उनके पास फ़ाइल तक पहुंच नहीं है।

वास्तव में फ़ाइल को देखने में सक्षम लोगों के लिए आपको दोनों अनुमतियां सेट करने की आवश्यकता होती है ।

पीजी में एक ही बात। किसी तालिका पर USAGEजैसे किसी ऑब्जेक्ट पर कार्रवाई करने के लिए आपको स्कीमा अधिकार और ऑब्जेक्ट अधिकार दोनों चाहिए SELECT।

(सादृश्य नीचे एक सा हो जाता है में है कि PostgreSQL, अभी तक पंक्ति-स्तर सुरक्षा की जरूरत नहीं है तो उपयोगकर्ता अभी भी कर सकते हैं द्वारा "देख" उस तालिका स्कीमा में मौजूद है SELECTसे ing pg_classनहीं कर सकते सहभागिता इसके साथ किसी भी तरह से सीधे। वे , हालांकि, यह सिर्फ "सूची" हिस्सा है जो कि समान नहीं है। "

Comments

अब यह निर्देशिका उदाहरण के साथ बहुत स्पष्ट है :) मुझे यह कहना होगा कि यदि आप सुपरग्यूसर के साथ कुछ तालिका या पंक्ति डालते हैं तो यह एक समस्या है, उदाहरण के लिए जब आप पोस्टगिस का उपयोग करते हैं CREATE EXTENSION। यह कमोबेश यही समस्या लिनक्स पर बनी फाइलों के साथ है su। sudo -ePqsl में कथनों के लिए एक प्रकार है तो अच्छा होगा ।

— मार्को सुल

वैसे भी अब मुझे एहसास हुआ कि GRANTसारणी के लिए विशिष्ट कथन नहीं हैं जो मैं चाहता हूं, क्योंकि वे सभी डेटाबेस को प्रभावित करते हैं ...: s

— मार्को सुल

@LucasMalor एर ... नहीं, वे नहीं। GRANTएक स्कीमा उस स्कीमा को प्रभावित करता है। GRANT ... ON ALL TABLES IN SCHEMA ...एक विशेष डेटाबेस में स्कीमा में सभी तालिकाओं को प्रभावित करता है। ऐसे कोई भी GRANTs नहीं हैं जो सभी डेटाबेस को प्रभावित करते हैं (ठीक है, GRANTउपयोगकर्ता को आईएनजी सदस्यता को छोड़कर )।

— क्रेग रिंगर

आह, मुझे माफ करना, मैंने उन बयानों को निष्पादित किया जब मुझे "पोस्टग्रेज" सुपरयुजर के रूप में लॉग इन किया गया था, और उन्होंने "पोस्टग्रेज" डेटाबेस को प्रभावित किया। मैंने सोचा था कि यदि आप psqlबिना -d dbकिसी db के "बाहर" काम कर रहे हैं, लेकिन आप हमेशा एक db से जुड़े रहते हैं और डिफ़ॉल्ट रूप से आप db से अपनी भूमिका के समान नाम से जुड़े होते हैं। db = भूमिका = उपयोगकर्ता = समूह ... यह थोड़ा भ्रमित करने वाला है: D

— Marco Sulla

@LucasMalor इस तरह से सोचें। डिफ़ॉल्ट रूप से आप डीबी से उसी नाम से जुड़ते हैं जिस लॉगिन भूमिका ("उपयोगकर्ता") से आप कनेक्ट होते हैं। "उपयोगकर्ता" केवल भूमिकाएं हैं WITH LOGIN; अनिवार्य रूप से, सब कुछ एक समूह हो सकता है, और समूहों में लॉग इन करने में सक्षम होने के लिए सेट किया जा सकता है।

— क्रेग रिंगर

Answer 2

उत्पादन प्रणाली के लिए, आप इस विन्यास का उपयोग कर सकते हैं:

--ACCESS DB
REVOKE CONNECT ON DATABASE nova FROM PUBLIC;
GRANT  CONNECT ON DATABASE nova  TO user;

--ACCESS SCHEMA
REVOKE ALL     ON SCHEMA public FROM PUBLIC;
GRANT  USAGE   ON SCHEMA public  TO user;

--ACCESS TABLES
REVOKE ALL ON ALL TABLES IN SCHEMA public FROM PUBLIC ;
GRANT SELECT                         ON ALL TABLES IN SCHEMA public TO read_only ;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO read_write ;
GRANT ALL                            ON ALL TABLES IN SCHEMA public TO admin ;

Comments

स्कीमा पर adminभी नहीं दिया जाना चाहिए CREATE?

— दान

पहुँच एक पदानुक्रमित मॉडल के अनुसार आवंटित की जाती है: BD -> SCHEMA -> टैब । के साथ GRANT USAGE ON SCHEMA, व्यवस्थापक उपयोगकर्ता तालिका नहीं बना सकता है, लेकिन वह इसके साथ कर सकता है ALL GRANT ALL ON SCHEMA....

— bilelovitch

@बिल्लोविच: आपका मतलब है grant all on schema public to admin? पुनश्च: मैंने यह भी जोड़ा grant usage, select on all sequences in schema public to read_only/read_write; grant execute on all functions in schema public to read_only/read_write;

— मार्को सुल

Answer 3

ठीक है, यह लिनक्स के लिए एक साधारण db के लिए मेरा अंतिम समाधान है:

# Read this before!
#
# * roles in postgres are users, and can be used also as group of users
# * $ROLE_LOCAL will be the user that access the db for maintenance and
#   administration. $ROLE_REMOTE will be the user that access the db from the webapp
# * you have to change '$ROLE_LOCAL', '$ROLE_REMOTE' and '$DB'
#   strings with your desired names
# * it's preferable that $ROLE_LOCAL == $DB

#-------------------------------------------------------------------------------

//----------- SKIP THIS PART UNTIL POSTGRES JDBC ADDS SCRAM - START ----------//

cd /etc/postgresql/$VERSION/main
sudo cp pg_hba.conf pg_hba.conf_bak
sudo -e pg_hba.conf

# change all `md5` with `scram-sha-256`
# save and exit

//------------ SKIP THIS PART UNTIL POSTGRES JDBC ADDS SCRAM - END -----------//

sudo -u postgres psql

# in psql:
create role $ROLE_LOCAL login createdb;
\password $ROLE_LOCAL
create role $ROLE_REMOTE login;
\password $ROLE_REMOTE

create database $DB owner $ROLE_LOCAL encoding "utf8";
\connect $DB $ROLE_LOCAL

# Create all tables and objects, and after that:

\connect $DB postgres

revoke connect on database $DB from public;
revoke all on schema public from public;
revoke all on all tables in schema public from public;

grant connect on database $DB to $ROLE_LOCAL;
grant all on schema public to $ROLE_LOCAL;
grant all on all tables in schema public to $ROLE_LOCAL;
grant all on all sequences in schema public to $ROLE_LOCAL;
grant all on all functions in schema public to $ROLE_LOCAL;

grant connect on database $DB to $ROLE_REMOTE;
grant usage on schema public to $ROLE_REMOTE;
grant select, insert, update, delete on all tables in schema public to $ROLE_REMOTE;
grant usage, select on all sequences in schema public to $ROLE_REMOTE;
grant execute on all functions in schema public to $ROLE_REMOTE;

alter default privileges for role $ROLE_LOCAL in schema public
    grant all on tables to $ROLE_LOCAL;

alter default privileges for role $ROLE_LOCAL in schema public
    grant all on sequences to $ROLE_LOCAL;

alter default privileges for role $ROLE_LOCAL in schema public
    grant all on functions to $ROLE_LOCAL;

alter default privileges for role $ROLE_REMOTE in schema public
    grant select, insert, update, delete on tables to $ROLE_REMOTE;

alter default privileges for role $ROLE_REMOTE in schema public
    grant usage, select on sequences to $ROLE_REMOTE;

alter default privileges for role $ROLE_REMOTE in schema public
    grant execute on functions to $ROLE_REMOTE;

# CTRL+D

Comments

"# सभी तालिकाएँ और ऑब्जेक्ट बनाएँ, और उसके बाद:" के लिए किस उपयोगकर्ता का उपयोग किया जाना है? आपके मामले में तालिकाओं और अन्य वस्तुओं का मालिक कौन है?

— क्रिस्टोफ फुरमानीक

@ChristopheFurmaniak आप सही हैं, मैंने इस प्रक्रिया को ठीक किया। Db और इसके ऑब्जेक्ट्स का मालिक $ $ ROLE_LOCAL है और, db संरचना तैयार करने के बाद, हमें सुपरयूज़र को पोस्टग्रेट करना होगा।

— मार्को सुल्टा

मेरा मानना ​​है कि आपके पास "ALTER DEFAULT PRIVILEGES ..." कमांड में एक मुद्दा है। इस आदेश का उपयोग किसी उपयोगकर्ता (भूमिका) को अनुदान विशेषाधिकार ट्रिगर करने के लिए किया जाता है जब एक अलग उपयोगकर्ता (भूमिका) एक वस्तु बनाता है। स्पष्टीकरण के लिए इस दस्तावेज़ का पृष्ठ 11, अनुभाग 7.1 देखें । वर्तमान में आपके ROLE_REMOTE में उन सभी वस्तुओं तक पहुंच नहीं होगी जो ROLE_LOCAL बनाएगी। ROLE_LOCAL कमांड केवल निजी दे रही है कि भूमिका में पहले से ही उन वस्तुओं का स्वामी है। एक ही ROLE_REMOTE कमांड के लिए जाता है।

— 21