Як керувати ПОСЛУГИМИ ПРИВІЛЕГАМ для ПОТРІБНИКІВ НА ДАТАБАСІ проти ШЕМИ?

Я хочу перенести досить простий, внутрішній додаток, керований базами даних, від SQLite3 до PostgreSQL 9.3 і посилити дозволи в БД під час проходження.

Зараз додаток складається з команди оновлення даних; і один для запиту. Звичайно, мені також потрібно буде підтримувати базу даних іншими способами (створювати нові таблиці, перегляди, тригери тощо).

Хоча ця програма спочатку буде єдиним розміщеним на сервері, я вважаю за краще припустити, що в майбутньому він може розміщуватися на сервері з іншими базами даних, а не пізніше виконувати завдання, якщо це стане необхідним у майбутнє.

Я думаю, що це буде досить поширений набір вимог, але у мене виникають проблеми з пошуком простого підручника, що пояснює, як створити нову базу даних у PostgreSQL, з таким поділом користувачів / привілеїв. Посилання продовжуються щодо груп, користувачів, ролей, баз даних, схем та домену; але я вважаю їх заплутаними.

Ось що я спробував до цього часу (зсередини psqlяк "postgres"):

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та, можливо, інших об'єктів).

Де я можу знайти гідне керівництво, навчальний посібник чи відео серіал з цього приводу?

Де я можу знайти гідне керівництво, навчальний посібник чи відео серіал з цього приводу?

Ви знайдете все в посібнику. Посилання нижче.
Звичайно, справа не тривіальна, а іноді і заплутана. Ось рецепт випадку використання:

Рецепт

Я хочу, щоб він був налаштований так, що тільки 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 alterSEE примітках нижче.

У міру того, як все стане вдосконаленим, у мене також будуть питання щодо застосування подібних обмежень щодо TRIGGERSзбережених процедур VIEWSта, можливо, інших об'єктів.

Погляди особливі. Для одного:

... (але зауважте, що ALL TABLESвважається, що він включає перегляди та зовнішні таблиці).

А для оновлених переглядів :

Зауважте, що користувач, який виконує вставку, оновлення або видалення у представленні даних, повинен мати відповідну вставку, оновлення або видалення привілею для подання. Крім того, власник представлення повинен мати відповідні привілеї щодо базових базових відносин, але користувачеві, який виконує оновлення, не потрібні дозволи на базові базові відносини (див. Розділ 38.5 ).

Тригери теж особливі. Вам потрібна TRIGGERпривілей на столі та:

• Які привілеї необхідні для виконання тригерної функції в PostgreSQL 8.4?

Але ми вже надто розширюємо сферу цього питання ...

Важливі примітки

Власність

Якщо ви хочете дозволити schma_admin(поодинці) скидати та змінювати таблиці, зробіть роль власником усіх об'єктів. Документація:

Право скинути об’єкт або змінити його визначення будь-яким чином не розглядається як привілей, що можна отримати; вона притаманна власнику і не може бути надана або відкликана. (Однак подібний ефект можна отримати, надавши або скасувавши членство в ролі, якій належить об'єкт; див. Нижче.) Власник неявно також має всі варіанти надання об’єкта.

ALTER TABLE some_tbl OWNER TO schma_admin;

Або створити всі об'єкти з роліschma_adminдля початку, тоді не потрібно чітко встановлювати власника. Це також спрощує привілеї за замовчуванням, які вам слід встановити лише для однієї ролі:

Попередньо існуючі об’єкти

Привілеї за замовчуванням застосовуються лише для новостворених об'єктів і лише для певної ролі, з якою вони створюються. Ви також хочете адаптувати дозволи для існуючих об'єктів:

• Дозвіл відмовлено у відношенні <table>

Це ж стосується, якщо ви створюєте об'єкти з не визначеною роллю DEFAULT PRIVILEGES, як суперпользователь postgres. Перепрісвоіть власності на schma_adminі набір привілеїв вручну - або набір DEFAULT PRIVILEGESдля , postgresа також (при підключенні до правої БД!):

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

Привілеї за замовчуванням

Ви пропустили важливий аспект ALTER DEFAULT PRIVILEGESкоманди. Він застосовується до поточної ролі, якщо не вказано інше:

• Неможливо змінити привілеї за замовчуванням

Привілеї за замовчуванням застосовуються лише до поточної бази даних. Таким чином, ви не вадитесь з іншими базами даних у кластері DB. Документація:

для всіх об'єктів, створених у поточній базі даних

Ви можете також необхідно встановити права по замовчуванням для FUNCTIONSі TYPES(не тільки TABLESі SEQUENCES), але ті , які не можуть бути необхідні.

Привілеї за замовчуванням для PUBLIC

Пільги за замовчуванням, які надаються, PUBLICє рудиментарними та деякими завищеними. Документація:

PostgreSQL надає пільги за замовчуванням для деяких типів об'єктів PUBLIC. Не застосовуються пільги PUBLICза замовчуванням у таблицях, стовпцях, схемах або табличних просторах. Для інших типів надані пільги за замовчуванням PUBLICтакі: CONNECTта CREATE TEMP TABLEдля баз даних; EXECUTEпривілей на функції; та USAGE привілей на мови.

Сміливий акцент мій. зазвичай однієї команди вище, достатньо, щоб охопити все:

REVOKE ALL ON DATABASE hostdb FROM public;

Зокрема, 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. Інше (скоріше) встановлює його як властивість бази даних, або просто для залучених ролей або навіть поєднання обох. Деталі:

• Як впливає search_path на роздільну здатність ідентифікатора та "поточну схему"

Ви можете встановити його, schma, publicякщо ви також використовуєте загальнодоступну схему, або навіть (менш ймовірно) $user, schma, public...

Альтернативою може бути використання схеми за умовчанням "public", яка повинна працювати з налаштуваннями за замовчуванням, search_pathякщо ви не змінили це. Не забудьте скасувати привілеї для PUBLICцього випадку.

Пов'язані

• Надання пільг для певної бази даних в PostgreSQL
• PostgreSQL - користувачеві БД слід дозволити лише викликувати функції