SCHATA vs DATABASE KULLANICILARI için DEFAULT PRIVILEGES nasıl yönetilir?

Oldukça basit, dahili, veritabanı tabanlı bir uygulamayı SQLite3'ten PostgreSQL 9.3'e geçirmek ve kullandıkça DB'deki izinleri sıkmak istiyorum.

Uygulama şu anda verileri güncelleme komutundan oluşur; ve sorgulamak için bir tane. Doğal olarak, veritabanını başka şekillerde de korumam gerekecek (yeni tablolar, görünümler, tetikleyiciler vb.).

Bu uygulama ilk önce sunucuda barındırılan tek uygulama olacak olsa da, daha sonra gerekli olması halinde daha sonra karıştırılması gerekmek yerine, gelecekte başka veritabanlarıyla bir sunucuda barındırılabileceği varsayımıyla pişirmeyi tercih ederim. gelecek.

Bunların oldukça yaygın bir gereksinimler kümesi olacağını düşünürdüm, ancak PostgreSQL'de bu tür bir kullanıcı / ayrıcalık ayrımı ile nasıl yeni bir veritabanı kurulacağını açıklayan basit bir rehber bulmakta güçlük çekiyorum. Referanslar gruplar, kullanıcılar, roller, veritabanları, şemalar ve etki alanı hakkında uzun sürüyor; ama onları kafa karıştırıcı buluyorum.

İşte şimdiye kadar psqldenediklerim (içinden 'postgres' olarak):

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;

Ama amaçlanan semantiği anlamıyorum. Yapılandırılmasını istiyorum, böylece sadece hostdb_admintablolar oluşturabilir (ve bırakıp değiştirebilir); hostdb_mgrokuma, güncelleme yerleştirin ve varsayılan olarak tüm tabloları silebilirsiniz; ve hostdb_usryalnızca tüm tabloları (ve görünümleri) okuyabilir.

Bunu denediğimde hostdb, bu kullanıcıların herhangi birinde tablo oluşturabildiğimi gördüm ; ancak, her kullanıcı için, açıkça kullanmadığım sürece, o kullanıcı tarafından oluşturulan tabloları okuyabilir veya değiştirebilirim GRANT.

Orada en şey arasındaki kayıp olduğunu tahmin ediyorum CREATE DATABASEve CREATE SCHEMAuygulamak için bir şey SCHEMAiçin DATABASE?

(İşler daha da geliştikçe TRIGGERS, benzer kısıtlamaları , saklı yordamları VIEWSve belki de diğer nesneleri uygulamak için de sorularım olacak ).

Bu konuda iyi bir rehber, eğitim veya video dizisini nerede bulabilirim?

Bu konuda iyi bir rehber, eğitim veya video dizisini nerede bulabilirim?

Her şeyi kılavuzda bulacaksınız . Aşağıdaki linkler.
Verilen, önemsiz ve bazen kafa karıştırıcı değil. İşte kullanım durum için bir reçete:

Yemek tarifi

Yapılandırılmasını istiyorum, böylece sadece hostdb_admintablolar oluşturabilir (ve bırakıp değiştirebilir); okuma, güncelleme yerleştirin ve varsayılan olarak tüm tabloları silebilirsiniz; ve yalnızca tüm tabloları (ve görünümleri) okuyabilir.
hostdb_mgr
hostdb_usr

Süper kullanıcı olarak 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';

Veritabanlarını ve rollerini de yönetebilen daha güçlü bir yönetici istiyorsanız, rol niteliklerini CREATEDBveCREATEROLE üstünü ekleyin .

Her bir rolü bir üst seviyeye verin, böylece tüm seviyeler en azından bir sonraki alt seviyeden ayrılan ayrıcalıkları “miras” altına alın (kademeli):

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

Şemayı adlandırıyorum schma( hostdbkafa karıştırıcı olmaz). Herhangi bir isim seç. İsteğe bağlı olarak yapmak schma_adminşemanın sahibi:

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 alterAşağıdaki notları görmek için .

İşler daha da geliştikçe TRIGGERS, benzer kısıtlamaları , saklı yordamları VIEWSve belki de diğer nesneleri uygulamak için de sorularım olacak .

Görüşler özeldir. Bir kişi için:

... (ancak ALL TABLESgörüş ve yabancı tabloları içerdiği kabul edilir).

Ve Güncellenebilir Görünümler için :

Görünümde ekleme, güncelleme veya silme işlemini gerçekleştiren kullanıcının görünümde ilgili ekleme, güncelleme veya silme ayrıcalığına sahip olması gerektiğini unutmayın. Ek olarak, görünümün sahibi, temel dayanak ilişkileri üzerinde ilgili imtiyazlara sahip olmalıdır, ancak güncellemeyi yapan kullanıcının temel dayanak ilişkileri üzerinde herhangi bir izne ihtiyacı yoktur (bkz. Bölüm 38.5 ).

Tetikleyiciler de özeldir. TRIGGERMasadaki ayrıcalığa ihtiyacınız var ve:

• PostgreSQL 8.4'te bir tetikleyici işlev yürütmek için gereken ayrıcalıklar nelerdir?

Ama biz zaten bu sorunun kapsamını genişletiyoruz ...

Önemli notlar

sahiplik

İzin vermek isterseniz schma_adminbırakın ve alter tablolar, rol yapma (tek başına) sahip tüm nesneleri. Dökümantasyon:

Bir nesneyi düşürme veya tanımını herhangi bir şekilde değiştirme hakkı, bir büyütülebilir imtiyaz olarak değerlendirilmez; mal sahibine özgüdür ve verilemez veya iptal edilemez. (Bununla birlikte, benzer bir etki, nesnenin sahibi olduğu rolde üyeliğin verilmesi veya iptal edilmesiyle elde edilebilir; aşağıya bakın.) Sahip, dolaylı olarak nesne için de tüm hibe seçeneklerine sahiptir.

ALTER TABLE some_tbl OWNER TO schma_admin;

Ya daschma_admin başlamasıgereken rolle birlikte tüm nesneleri oluşturun, ardından sahibi açıkça ayarlamanız gerekmez. Ayrıca, daha sonra yalnızca bir rol için ayarlamanız gereken varsayılan ayrıcalıkları da basitleştirir:

Önceden var olan nesneler

Varsayılan ayrıcalıklar, yalnızca yeni oluşturulan nesneler için ve yalnızca birlikte oluşturdukları belirli rol için geçerlidir. Siz de mevcut nesneler için izinleri uyarlamak isteyeceksiniz :

• <table> ilişkisi için izin verilmedi.

Aynısı DEFAULT PRIVILEGES, süper kullanıcı gibi ayarlanmamış bir rolü olan nesneler oluşturursanız da geçerlidir postgres. Yeniden atama sahiplik schma_adminelle ve seti ayrıcalıkları - veya set DEFAULT PRIVILEGESiçin postgresde (sağ DB bağlıyken!):

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

Varsayılan ayrıcalıklar

ALTER DEFAULT PRIVILEGESKomutun önemli bir yönünü özlüyordun. Aksi belirtilmedikçe mevcut rol için geçerlidir:

• Varsayılan ayrıcalıkları değiştiremezsiniz

Varsayılan ayrıcalıklar yalnızca mevcut veritabanına uygulanır. Böylece DB kümesindeki diğer veritabanlarıyla uğraşmazsınız. Dökümantasyon:

Geçerli veritabanında oluşturulan tüm nesneler için

Sen olabilir ayrıca ayarlanan varsayılan ayrıcalıkları için istediğiniz FUNCTIONSve TYPES(sadece TABLESve SEQUENCES), ancak bu gerekli olmayabilir.

İçin varsayılan ayrıcalıklar PUBLIC

Verilen varsayılan imtiyazlar PUBLICtemeldir ve bazıları tarafından fazla tahmin edilir. Dökümantasyon:

PostgreSQL bazı nesneler için varsayılan ayrıcalıklar verir PUBLIC. Tablolarda, sütunlarda, şemalarda veya tablo alanlarında varsayılan olarak hiçbir ayrıcalık verilmez PUBLIC. Diğer türler için verilen varsayılan ayrıcalıklar PUBLICaşağıdaki gibidir: CONNECTve CREATE TEMP TABLEveritabanları için; EXECUTEişlevler için ayrıcalık; ve USAGE diller için ayrıcalık.

Cesur vurgu benim. genellikle yukarıdaki bir komut her şeyi kapsayacak şekilde yeterlidir:

REVOKE ALL ON DATABASE hostdb FROM public;

Özellikle, PUBLICyeni şemalar için varsayılan ayrıcalıklar verilmez . "Public" adlı varsayılan şemanın ALLiçin ayrıcalıklarla başlaması kafa karıştırıcı olabilir PUBLIC. Bu sadece yeni oluşturulan veritabanları ile başlangıcı kolaylaştırmak için kolaylık sağlayan bir özelliktir. Diğer şemaları hiçbir şekilde etkilemez. Sen edebilirsiniz Şablon veritabanında bu ayrıcalıkları iptal template1sonra bu kümedeki tüm yeni oluşturulan veritabanları onlarsız başlar:

\connect template1
REVOKE ALL ON SCHEMA public FROM public;

Ayrıcalık TEMP

Tüm ayrıcalıkları iptal ettiğimiz hostdbiçin PUBLIC, düzenli olarak izin vermediğimiz sürece normal kullanıcılar geçici tablolar oluşturamazlar. Bunu eklemek isteyebilir veya istemeyebilirsiniz:

GRANT TEMP ON DATABASE hostdb TO schma_mgr;

search_path

Ayarlamayı unutma search_path. Kümede yalnızca bir veritabanı varsa, genel varsayılanı sadece ayarlayabilirsiniz postgresql.conf. Başka (daha muhtemel), veritabanının özelliği olarak veya yalnızca ilgili roller ve hatta ikisinin birleşimi için ayarlayın. Detaylar:

• Search_path tanımlayıcı çözünürlüğünü ve “geçerli şema” yı nasıl etkiler?

schma, publicGenel şemayı da kullanıyorsanız, belki de (daha az olasılıkla) kullanmak isteyebilirsiniz $user, schma, public...

Bir alternatif, search_pathsiz değiştirmediğiniz sürece varsayılan ayarlarla çalışması gereken "public" varsayılan şemasını kullanmak olacaktır . PUBLICBu durumda ayrıcalıkları iptal etmeyi unutmayın .

İlgili

• PostgreSQL'de belirli bir veritabanı için yetkiler verin
• PostgreSQL - DB kullanıcısının sadece fonksiyonları çağırmasına izin verilmelidir.