2. Створення і ліквідація ролей

Для створення нової ролі використовується оператор CREATE ROLE, що визначається наступним синтаксичним правилом:

CREA ТЕ ROLE role_пате [ WITH ADMIN { CURRENT_USER CURRENT_ROLE } ]

Ім’я створюваної ролі повинне відрізнятися від будь-якого ідентифікатора авторизації, уже визначеного й збереженого в базі даних. У разі успішного створення ролі деякий authID отримує привілей на виконання даної ролі. Якщо в операторові CREATE ROLE не міститься розділ WITH ADMIN, то привілей на виконання ролі отримує поточний ідентифікатор користувача SQL-сесії, якщо значення цього ідентифікатора відмінне від NULL; інакше привілей на виконання ролі дається поточному імені ролі сесії.

Якщо до складу оператора включається розділ WITH ADMIN, то можна вибрати, чи буде власником ролі authID, відповідний поточному ідентифікатору користувача SQL-сесії, або authID, відповідний поточному імені ролі (за умови, що відповідні поточний ідентифікатор або поточне ім’я не містять NULL). Крім того, включення цього розділу означає, що authID- власник ролі отримує право на передачу привілею виконання даної ролі іншим authID.

Відповідно до стандарту SQL: 1999, привілеї, потрібні для виконання оператора CREATE ROLE, визначаються в реалізаціях SQL. Наприклад, у деяких реалізаціях виконання цієї операції вирішується адміністратором бази даних.

Існуючу роль можна ліквідовувати за допомогою оператора:

DROP ROLE role_name.

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

2. Передача привілеїв і ролей

Для передачі привілеї і ролей від одних authID іншим підтримується оператор GRANT’ якого ми обговоримо окремо для випадків передачі привілею і передачі ролей.

У разі передачі привілеїв використовується наступний синтаксис оператора GRANT:

GRANT { ALL PRIVILEGES privilege_commalist}

ON privilege_object TO { PUBLIC authID_commalist} [ WITH GRANT OPTION]

[GRANTED BY {CURRENTJJSER CURRENT_ROLE} ] privilege :: = SELECT[column_name;_commalist]

DELETE

INSERT [ column_name_commalisi ]

UPDATE [ column_name_commalist ]

REFERENCES [ column_name_commalist ]

USAGE

TRIGGER

execute \

privilege_object ::= [ TABLE] table name DOMAIN domain jiame CHARACTER SET character set name COLLATION collationname TRANSLA TION translationname У списку привілеїв можна використовувати SELECT, DELETE, INSERT, UPDATE, REFERENCES і TRIGGER тільки у тому випадку, коли як об'єкт привілеїв указується таблиця. Відповідно, список привілеїв може складатися з єдиного привілею USAGE тільки у тому випадку, коли об'єктом є домен, набір символів, порядок сортування або трансляції. Якщо в списку привілеїв указується більш ніж один привілей, то вони всі передаються вказаним authID, але для цього поточний authID SQL-сесії повинен володіти привілеєм на передачу привілеїв.

Використання ключового слова ALL PRIVILEGES замість явного завдання списку привілеїв означає, що передаються всі привілеї доступу до відповідного об'єкту бази даних, який має поточний authID SQL-сесії.

Як показує синтаксис, один оператор GRANT дозволяє передавати привілеї доступу до одного об'єкту, але у тому випадку, коли об’єктом є таблиця, різні привілеї можуть передаватися по відношенню до одного і

тому ж набору колонок або до різних наборів. Якщо при вказівці привілеїв DELETE, UPDATE i REFERENCES список імен колонок не визначається, передаються привілеї По відношенню до -всіх колонок таблиці, відзначимо, що ці привілеї стосуються всіх існуючйх стовпів даної таблиці, а також всіх колонок, які коли-небудь будуть до неї додані.

Включення в операторі необов'язкового розділу WITH GRANT ОРТION означає, що одержувачам передаваних привілеїв дається також привілей на подальшу передачу отриманих привілеї, включаючи привілей передачу привілеї. Включення в оператора розділу GRANTED BY дозволяє явно вказати, чи передаються привілеї від імені поточного ідентифікатора користувача або ж поточного імені ролі.

При перевірці можливості виконання операції в SQL-ceci) враховуються привілеї поточного authID SQL-сесії, а також привілеї всіх ролей, які передані даному authID. Оскільки цим ролям могли бути передані інші ролі, що володіють власними привілеями, аналіз можливості виконання операції є рекурсивною процедурою.

Якщо один і той же привілей передається більше одного разу одному і тому ж authID2 від імені одного і того ж authlDl, то виникає ситуація, звана надмірним дублюючим привілеєм. Ця ситуація не викликає додаткових проблем, оскільки надмірна передача привілеюі ігнорується. Для анулювання даного привілею у authID2 від імені authID2 потрібне виконання лише однієї операції REVOKE . Якщо привілей був один раз переданий authID2 від імені authID1 разом з привілеєм на передачу цьому привілею (WITH GRANT OPTION), а іншим разом - без цієї опції (порядок дій не є істотним), то authID2 має даний привілей і привілей на її передачу.

Якщо робиться спроба передачі декількох привілеїв, але відповідний authID не має жодного з них, то фіксується помилка. Аналогічно, якщо проводиться спроба передачі декількох привілеїв з можливістю мати привілеї на передачу привілеїв, але відповідний authID не має привілею WITH GRANT OPTION для жодного з передаваних привілеїв, то фіксується помилка. Привілеї конкретному користувачеві можуть бути призначені адміністратором явно, або неявно, наприклад через роль. Вирази керування привілеями:

призначення привілею:

GRANT привілей [ON об'єкт] ТО суб'єкт [WITH GRANT OPTION] скасування привілею:

REVOKE привілей [ON об'єкт] FROM суб'єкт Якщо суб'єкт=користувач, то привілей призначається йому явно. Якщо суб'єкт=роль, то для керування привілеями використаються відповідно:

GRANT ROLE ім'я ролі [ON об'єкт] ТО суб'єкт [WITH GRANT OPTION]

REVOKE ROLE ім'я_ролі [ON об'єкт] FROM суб'єкт

Призначення привілею всім користувачам системи здійснюється в такий спосіб:

GRANT привілей [ON об'єкт] ТО PUBLIC

У цьому випадку кожний новий створений користувач автоматично одержить такий привілей. Скасування привілею здійснюється так:

REVOKE привілей [ON об'єкт] FROM PUBLIC

Необхідно мати на увазі, що деякі реалізації SQL, наприклад IBM DB2, використають групи користувачів, певні в операційній системі. Тому варто звертати увагу на особливості реалізації аналогів ролей у СУБД. Потрібно з'ясувати, чи містить реалізація SQL-вирази:

CREATE ROLE ім'я_ролі DROP ROLE ім'я_ролі Приклад 6.1. Використання ролей.

Створимо роль stud і включимо в цю роль двох користувачів userl і user2: .

spaddrole 'student' sp addrolemember 'student', 'userl' spaddrole member 'student'user2'

Надамо права ролі stud і безпосередньо користувачеві user2:

GRANT SELECT, INSERT ON Stud TO student GRANT SELECT, INSERT ON Stud TO user2 Після виконання цих команд користувачі userl і user2 можуть виконувати команди вибірки й додавання запису в таблицю Stud. Призупинимо право на виконання вставки в таблицю Stud для ролі stud:

REVOKE INSERT ON Stud TO student Після виконання попередньої команди користувач userl втрачає право вставки запису, a user2 зберігає це право, оскільки право вставки надане йому явно. Виконаємо команду DENY INSERT ON Stud ТО student.

Після виконання цієї команди обидва користувачі втрачають права вставки в таблицю Stud. Застосування операторів груп Transaction Control Language (TCL) та Cursor Control Language (CCL) розглянемо дещо далі.