Если у вас возникли сложности с курсовой, контрольной, дипломной, рефератом, отчетом по практике, научно-исследовательской и любой другой работой - мы готовы помочь.
Предоплата всего
Подписываем
Розділ 20. Ролі та привілеї баз даних
PostgreSQL
працює з дозволами доступу до бази даних, використовуючи концепцію ролей. Роллю може бути один користувач, група користувачів, залежно від того як задається роль. Ролі можуть будти власниками обєктів бази даних (наприклад, таблиць) і привоювати привілеї для цих обєктів для контролю того, хто має доступ до цих обєктів. Більше того, можливо надавати членство одній ролі в іншій ролі, тобто дозволяти члену однієї ролі користуватись привілеями іншої ролі.
Концепція ролей сумує концепції користувачів та груп. В версіях PostgreSQL
перед 8.1, користувачі та групи були різними видами, але зараз це всього лиш ролі. Кожна роль може представляти користувача, групу, або обидвох їх.
Ця частина розказує як створити і управляти ролями і представляє систему привілеїв. Більше інформації про різні типи обєктів бази даних і роботи привілеїв можна знайти в розділі 5.
Ролі баз даних відрізняються від концепції користувачів операційної системи. На практиці може біти зручно використовувати відповідність, але не обовязково. Ролі в базах даних є глобальними для кластера бази даних (а не на окрему базу даних). Для створення ролі використовуйте команду:
CREATE ROLE name;
name
відповідає правилам найменування ідентифікаторів SQL
. (на практиці ви захочете додати якісь опції до команди, наприклад LOGIN
. Більше про це буде пізніше). Щоб видалити існуючу роль, використайте аналогічну команду:
DROP ROLE name;
Для зручності команди createuser і dropuser
є розширенням цих команд, які можуть викликатись із оболонки:
createuser name
dropuser name
Для визначення існуючого набору ролей, перевірте системний каталог pg_roles
, для прикладу
SELECT rolname FROM pg_roles;
Метакоманда psql
\du
також використовується для виводу існуючих ролей.
Для роботи з системою, нова системи завжди має задану роль. Ця роль є суперкористувачем, і по замовчуванню вона буде мати імя користувача операційної системи, який ініціалізував кластер бази даних. Також вона може називатись postgres.
Для створення інших ролей ви маєте підключити цю роль.
Кожне зєднання до сервера бази даних використовуює імя, або окрему роль, і ця роль визначає привілеї доступу для команд у цьому зєднанні. Імя ролі для використання в окремому зєднанні бази даних визначається за клієнтом, який ініціює запит зєднання в окремий спосіб. Для прикладу, програма psql
використовує опцію -U
для визначення, яку роль підключати. Більшість додатків вибирають імя поточного користувача операційної системи (включаючи createuser і psql
) Тому часто зручно встановлювати відповідність між користувачами ОС та ролями.
Роль бази даних може мати певні атрибути, що визначають привілеї і працюють із системою аутентифікації клієнта
Привілей входу
Тільки ролі, що мають атрибут LOGIN
можуть використовуватись як роль для зєднання з базою даних. Роль з атрибутом LOGIN
може сприйматись як “користувач бази даних”. Для створення такої ролі використовуйте одне з двох:
CREATE ROLE name LOGIN;
CREATE USER name;
(CREATE USER ідентичне CREATE ROLE
, але CREATE USER
передбачає LOGIN
по замочуванню, а CREATE ROLE
- ні)
Статус супекористувача
суперкористувач бази даних користується всіма привілеями. Це небезпечний привілей і має використовуватись з розумом. Краще робити свою роботу в ролі не суперкористувача. Для створення нового суперкористувача бази даних, використайте CREATE ROLE name SUPERUSER.
Ви маєте це робити, ввійшовши як суперкористувач.
Створення бази даних
Ця роль явно задає дозвіл створювати бази даних (для суперкористувачів це задано неявно). Щоб створити таку роль, використайте CREATE ROLE name CREATEDB.
Створення ролі
Роль може давати дозвіл на створення інших ролей. Щоб створити таку роль, використайте CREATE ROLE name CREATEROLE
. Роль з привілеєм CREATEROLE
може міняти і видаляти інші ролі, так само як надавати членство в них. Але для створення, редагування та видалення ролі суперкористувача, вимагається статус суперкористувача. CREATEROLE
для цього непотрібна.
Пароль
Пароль має значення, коли метод аутентифікація клієнта вимагає ввести пароль при зєднанні з базою даних. Методи password і md5
використовують паролі. Паролі баз даних є відмінними від паролів операційної системи. Вказання пароля відбувається з допомогою CREATE ROLE name PASSWORD ’string ’.
Атрибути ролі можуть мінятись після створення командою ALTER ROLE.
Дивіться довідку по командах CREATE ROLE та ALTER ROLE
.
Підказка: Хорошою практикою є створення ролі, яка матиме привілеї CREATEDB та CREATEROLE
, але не буде суперкористувачем, і використовувати цю роль для щоденного управління базами даних та ролями. Це дозволить уникати небезпек роботи в ролі суперкористувача над завданнями, які цього не вимагають.
Ролі також мають деякі специфічні замовчування для багатьох параметрів, описаних в розділі 18. Наприклад, якщо ви захотіли відключити сканування індексів (не найкраща ідея), ви можете використати:
ALTER ROLE myname SET statement_timeout = ’5min’;
Це береже опцію (але не змінить її негайно). В наступних зєднаннях цієї ролі все поде проходити через SET statement_timeout = ’5min’ перед стартом сесії. Ви можете міняти це значення протягом сесії. Воно просто буде по замовчуванню. Щоб видалити таке налаштування, використайте ALTER ROLE rolename RESET varname.
. Зауважте, що специфічна для ролі конфігурація, приєднана до ролей без привілея LOGIN
є непотрібною, оскільки викликатись не буде.
Коли обєкт створюється, він отримує власника. Власник це зазвичай роль, що виконує вираз створення. В більшості видів обєктів, власник або суперкористувач може робити з обєктом будь-що. Щоб дозволити таке іншим ролям, нам треба делегувати привілеї. Є декілька різних типів привілеїв: SELECT, INSERT, UPDATE, DELETE, TRUNCATE, REFERENCES, TRIGGER,
CREATE, CONNECT, TEMPORARY, EXECUTE і USAGE.
Для більшої інформації про них, дивіться сторінку довідки GRANT
.
Щоб привоїти привілеї, використайте команду GRANT . Тож якщо joe
це існуюча роль, а accounts
це таблиця, привілей для її оновлення може надатись з допомогою:
GRANT UPDATE ON accounts TO joe;
Специфічне імя PUBLIC
використовується для надання привілеїв всім ролям у системі. Написання ALL
замість специфікаціх привілеїв надасть усі привілеї заданій ролі.
Зоб відключити привілеї, використайте команду REVOKE
:
REVOKE ALL ON accounts FROM PUBLIC;
Спеціальні привілеї власника обєкту (право редагувати і знищувати обєкт) є неявними для власника і не можуть бути відібрані або надані. Але власник може вибрати відміну деяких привілеїв, наприклад зробити таблиці доступними тільки для читання для себе і для інших.
Обєкту може бути присвоєний новий власник використанням команди ALTER
певного типу обєкта. Суперкористувачі це також можуть робити. Стандартні ролі можуть це зробити, якщо вони є і поточним власником обєкта, і членом нової ролі власника.
Для груп користувачів часто зручно ділити управління привілеями. В PostgreSQL
робить створенням ролі, що представляє групу, і потім дозволити членство в груповій ролі для ролей окремого користувача. Для створення групової ролі, спочатку створіть роль:
CREATE ROLE name;
Типово роль, що використовується для групи, не смаж атрибуту LOGIN
, хоча ви можете за бажанням його встановити.
Коли групова роль існує, ви можете додавати і видаляти членів ролей, використовуючи команди GRANT і REVOKE
:
GRANT group_role TO role1, ... ;
REVOKE group_role FROM role1, ... ;
Ви можете надавати членство іншим груповим ролям також (оскільки немає різниці між груповими та негруповими ролями). База даних не дозволить вам встановити зациклені членства. Також заборонено надавати членство в ролі для PUBLIC.
Члени групової ролі можуть використовувати привілеї ролі двома способами. По-перше, всі члени ролі можуть явно робити SET ROLE , щоб тимчасово ставати груповою роллю. В цьому стані, сесія бази даних має доступ до привілеїв групової ролі, а не окремох ролі користувача, і всі обєкти, що створюються, відносяться до групової ролі. Наступне, ролі-члени, що мають атрибут INHERIT
, успадковують привілеї ролей, членами яких вони є, включаючи їх атрибут INHERIT
. Як приклад, припустимо, що ми зробили:
CREATE ROLE
joe LOGIN INHERIT;
CREATE ROLE
admin NOINHERIT;
CREATE ROLE
wheel NOINHERIT;
GRANT
admin
TO joe;
GRANT wheel
TO admin;
Після зєднання в ролі joe,
сесія бази даних буде використовувати привілеї, надані joe, плюс привілєї, надані admin,
оскільки joe
успадковує привілеї admin
. Хоча привілеї для wheel
не надаються, оскільки хоч joe
є непрямим членом wheel,
це членство здійснюється через admin
, який не має атрибуту INHERIT
. Після
SET ROLE admin;
Сесія буде використовувати тільки привієї надані admin,
а не ті, що надані joe.
Після SET ROLE wheel;
сесія буде використовувати тільки привілеї надані wheel,
і ніякі інші. Оригінальні привілеї можна відновити будь-яким із
SET ROLE joe;
SET ROLE NONE;
RESET ROLE;
Зауваження: команда SET ROLE
завжди дозволяє вибір будь-якої ролі, членом якої є поточна роль. Тому в попередньому прикладі, не потрібно ставати admin
, перед тим , як стати wheel.
Зауваження: в стандарті SQL
є чітке розділення між користувачами і ролями, і користувачі не успадковують привілеї автоматично, як це роблять ролі. Ця поведінка розділяється в PostgreSQL
тим, що ролям надається атрибут INHERIT
, тоді як ролям, що сприймаються як користувачі, присвоюється атрибут NOINHERIT
. Хоча по замовчуванню всім ролям надається атрибут INHERIT
, для сумісності із релізами до 8.1, де користувачі мали використовувати привілеї груп, членами яких вони були.
Атрибути ролей LOGIN, SUPERUSER, CREATEDB, та CREATEROLE
можуть сприйматись як спеціальні, але вони ніколи не є стандартними для обєктів бази даних. Ви мусите виконати SET ROLE
для окремої ролі, щоб встановити цей атрибут. Продовжуючи попередній приклад, ми можемо надати CREATEDB та CREATEROLE
ролі admin
. Тоді сесія joe
не буде мати цих привілеїв по замовчуванню, а тільки після SET ROLE admin.
Щоб видалити групову роль, використайте DROP ROLE:
DROP ROLE name;
Всі членства в груповій ролі видаляються (але ролі членів не зачіпаються). Зауважте, що всі обєкти створені групою, мають бути переприсвоєні іншим власникам, а всі дозволи, надані групі, мають відмінитись.
Функції та тригери дозволяють користувачам вставляти код в сервер, щоб інші користувачі його виконували. Обидва механізми дозволяють займатись “троянськими конями”. Єдиним захистом буде жорсткий контроль за тим, хто визначає функції.
Функції запускаються на серверному процесі з дозволами операційної системи для демона сервера бази даних. Якщо мова програмування, що використовується для функції дозволяє невідмічені доступи до памяті, можливо змінити внутрішню структуру даних сервера. Такі функції можуть модифікувати будь-який контроль за доступом до системи. Мови функцій, що дозволяють такий доступ, признаються недовіреними, і PostgreSQL
дозволяє створення функцій на цих мовах тільки з правами суперкористувача.