Використовуючи PostgreSQL 9.0, я маю групову роль, яка називається "персонал", і я хотів би надати всі (або певні) привілеї цій ролі в таблицях у певній схемі. Жодна з наступних робіт

GRANT ALL ON SCHEMA foo TO staff;
GRANT ALL ON DATABASE mydb TO staff;

Члени "staff" досі не можуть ВИБРАТИ або ОНОВИТИ за окремими таблицями у схемі "foo" або (у випадку другої команди) до будь-якої таблиці бази даних, якщо я не надаю все за цією конкретною таблицею.

Що я можу зробити, щоб полегшити своє життя та моїх користувачів?

Оновлення: зрозумів це за допомогою подібного запитання на serverfault.com .

GRANT ALL PRIVILEGES ON ALL TABLES IN SCHEMA foo TO staff;

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

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

Сміливий наголос мій. serialстовпці реалізовані nextval()в послідовності як за замовчуванням для стовпців і, цитуючи посібник :

Для послідовностей цей привілей дозволяє використовувати функції currvalі nextval.

Отже, якщо є serialстовпці, ви також захочете надати USAGE(або ALL PRIVILEGES) послідовності

GRANT USAGE ON ALL SEQUENCES IN SCHEMA foo TO mygrp;

Примітка: стовпці ідентичності в Postgres 10 або новіших версіях використовують неявні послідовності, які не потребують додаткових привілеїв. (Подумайте про оновлення serialстовпців.)

А як щодо нових об’єктів?

Ви також будете зацікавлені в DEFAULT PRIVILEGESкористувач або схеми :

ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT ALL PRIVILEGES ON TABLES TO staff;
ALTER DEFAULT PRIVILEGES IN SCHEMA foo GRANT USAGE          ON SEQUENCES TO staff;
ALTER DEFAULT PRIVILEGES IN SCHEMA foo REVOKE ...;

Це встановлює привілеї для об’єктів, створених у майбутньому автоматично, але не для вже існуючих об’єктів.

Привілеї за замовчуванням застосовуються лише до об’єктів, створених цільовим користувачем ( FOR ROLE my_creating_role). Якщо цей пункт пропущено, він за замовчуванням виконує поточного користувача ALTER DEFAULT PRIVILEGES. Щоб бути явним:

ALTER DEFAULT PRIVILEGES FOR ROLE my_creating_role IN SCHEMA foo GRANT ...;
ALTER DEFAULT PRIVILEGES FOR ROLE my_creating_role IN SCHEMA foo REVOKE ...;

Також зауважте, що всі версії pgAdmin III мають незначну помилку та відображають привілеї за замовчуванням на панелі SQL, навіть якщо вони не стосуються поточної ролі. Обов’язково налаштуйте FOR ROLEпункт вручну під час копіювання сценарію SQL.

Моя відповідь подібна до цієї на ServerFault.com .

Бути консервативним

Якщо ви хочете бути більш консервативними, ніж надання "всіх привілеїв", ви можете спробувати щось подібне.

GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public TO some_user_;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA public TO some_user_;

Використання publicтам посилається на назву схеми за замовчуванням, створеної для кожної нової бази даних / каталогу. Якщо ви створили схему, замініть власне ім’я.

Доступ до схеми

Щоб взагалі отримати доступ до схеми, для будь-якої дії користувачеві повинні бути надані права "використання". Перш ніж користувач зможе вибрати, вставити, оновити або видалити, спочатку користувачеві має бути надано «використання» схеми.

Ви не помітите цієї вимоги під час першого використання Postgres. За замовчуванням кожна база даних має першу схему з іменем public. І кожному користувачеві за замовчуванням автоматично надано права на використання цієї конкретної схеми. Додаючи додаткову схему, ви повинні чітко надати права на використання.

GRANT USAGE ON SCHEMA some_schema_ TO some_user_ ;

Витяг з документа Postgres :

Для схем надає доступ до об’єктів, що містяться у зазначеній схемі (припускаючи, що також виконуються власні вимоги до привілеїв об’єктів). По суті, це дозволяє грантоотримувачеві "шукати" об'єкти в схемі. Без цього дозволу все ще можна побачити імена об’єктів, наприклад, запитуючи системні таблиці. Крім того, після відкликання цього дозволу існуючі серверні резервні копії можуть мати оператори, які раніше виконували цей пошук, тому це не повністю безпечний спосіб запобігти доступу до об’єкта.

Для подальшого обговорення див. Запитання: Що саме ВИКОРИСТАННЯ ВИКОРИСТАННЯ НА СХЕМУ? . Зверніть особливу увагу на відповідь експерта Postgres Крейга Рінгера .

Існуючі об’єкти проти майбутнього

Ці команди впливають лише на існуючі об'єкти. Таблиці та подібні, які ви створюєте в майбутньому, отримують привілеї за замовчуванням, доки ви не виконаєте ці рядки вище. Дивіться іншу відповідь Ервіна Брандштеттера, щоб змінити значення за замовчуванням, впливаючи тим самим на майбутні об’єкти.