Завдання прав команда grant. Призначення та видалення прав. Надання привілеїв за допомогою with grant option
Платформа SQL Serverвикористовує інструкцію REVOKE як спосіб скасування налаштувань прав доступу, призначених даному користувачеві. Цей момент важливий, оскільки SQL Server підтримує додаткову інструкцію DENY, яка забороняє користувачеві доступ до вказаного ресурсу. У SQL Server інструкцію REVOKE можна використовувати для скасування привілеїв, призначених користувачеві за допомогою інструкції GRANT. Якщо ви хочете явно позбавити користувача певного привілею, вам слід використовувати інструкцію DENY.
Платформа SQL Server не підтримує пропозиції HIERARCHY OPTION та ADMIN OPTION стандарту ANSI. Хоча пропозиція ADMIN OPTION і не підтримується, у версії REVOKE SQL Server є два адміністративні привілеї (CREATE і BACKUP). Синтаксис наступної інструкції.
REVOKE ([об'єктний_привілей] [, …] | [системний_привілей]) [(стовпець [, …])]]| (ТО | FROM) (ім'я_отримувача [, …] | роль [, …] | PUBLIC | GUEST) ]
GRANT OPTION FOR
Користувач позбавляється права призначати конкретні привілеї іншим користувачам.
об'єктний привілей
Скасуються права доступу до різних інструкцій, які можуть бути комбіновані в будь-якому порядку.
ALL
Скасуються всі привілеї, призначені зараз зазначеним користувачам та/або для зазначених об'єктів бази даних. Використання цієї пропозиції не заохочується, оскільки сприяє нечіткості програмування.
(SELECT | INSERT DELETE UPDATE)
Зазначений користувач позбавляється зазначеного привілею доступу до зазначеного об'єкта (наприклад, таблиці або подання). Для скасування привілеїв рівня стовпця використовуйте список стовпців, що міститься у дужках.
REFERENCES
Скасується право створювати та видаляти обмеження типу «зовнішній ключ», що посилаються на об'єкт бази даних як на батьківський об'єкт.
Скасується право користувача створювати або видаляти правило у таблиці чи поданні.
Скасується право виконувати процедуру, що зберігається, користувальницьку функцію або розширену збережену процедуру.
системний привілей
Скасується право виконання наступних інструкцій: CREATE DATABASE, CREATE DEFAULT, CREATE FUNCTION, CREATE PROCEDURE, CREATE RULE, CREATE TABLE, CREATE VIEW, BACKUP DATABASE та BACKUP LOG.
ON [об'єкт] [(стовпець [, …])]
Скасується право доступу користувача до вказаного об'єкта. Якщо об'єкт є таблицею або поданням, ви можете скасовувати привілеї доступу до окремих стовпців. Ви можете скасовувати у таблиці або поданні привілею SELECT, INSERT, UPDATE, DELETE та REFERENCES. У стовпцях таблиці або подання ви можете скасовувати лише привілеї SELECT та UPDATE. Ви можете скасовувати привілеї EXECUTE в збереженій процедурі, функції користувача або розширеній збереженій процедурі.
[ТО | FROM] ім'я отримувача | роль | PUBLIC | GUEST
Вказуються користувачі або ролі, які втрачають цей привілей. Для скасування привілеїв, призначених ролі PUBLIC (яка має на увазі всіх користувачів), можна використовувати ключове слово PUBLIC. Можна перерахувати кілька одержувачів, розділяючи їх імена комами. У SQL Server також підтримується обліковий запис GUEST, яку використовують усі користувачі, які не мають свого запису в базі даних.
Видаляються привілеї користувачів, які отримали свої права через пропозицію WITH GRANT OPTION. Ця пропозиція є необхідною при використанні пропозиції GRANT OPTION FOR.
AS (ім'я_групи ім'я_ролі)
Вказуються права, відповідно до яких скасовується привілей. У деяких випадках користувачеві можуть тимчасово знадобитися права певної групи, щоб скасувати ці привілеї. У цьому випадку, щоб отримати такі права, ви можете використовувати пропозицію AS.
Дві форми інструкції REVOKE - REVOKE об'єктний привілей та REVOKE системний привілей є взаємовиключними. Не намагайтеся виконати обидві операції в одній інструкції. Ключова синтаксична відмінність між ними полягає в тому, що не слід використовувати пропозицію ON при видаленні системних привілеїв. Наприклад, щоб видалити системний привілей, можна використати таку команду.
REVOKE CREATE DATABASE, BACKUP DATABASE FROM dylan, katie
Якщо привілеї присвоєно користувачеві із застосуванням пропозиції WITH GRANT OPTION, то скасовувати ці привілеї слід з одночасним використанням двох пропозицій - WITH GRANT OPTION і CASCADE. Наприклад:
REVOKE GRANT OPTION FOR SELECT, INSERT, UPDATE, DELETE ON titles TO editors CASCADE GO
Команду REVOKE можна використовувати лише у поточній базі даних. Відповідно завжди неявно передбачаються опції стандарту ANSI CURRENTJJSER та CURRENTROLE. Інструкція REVOKE також використовується для скасування всіх параметрів DENY.
Платформа SQL Server також підтримує додаткову інструкцію DENY. Синтаксис інструкції DENY ідентичний синтаксису інструкції REVOKE. Однак, по суті вони відрізняються тим, що REVOKE нейтралізує привілеї користувача, а DENY їх явно забороняє. Використовуйте інструкцію DENY, щоб заборонити користувачеві або ролі доступ до привілею, навіть якщо привілей надається явно або через призначення ролі.
Інструкція REVOKE повинна використовуватись для видалення раніше наданих або заборонених (DENY) привілеїв. Наприклад, користувач kelly пішла у тривалу відпустку для догляду за дитиною. На цей час її доступ до таблиці працівників було заборонено. Вона повернулася, і ми знову дозволили привілеї.
DENY ALL ON employee TO Kelly GO
REVOKE ALL ON employee TO Kelly GO
У цьому прикладі команда REVOKE не видаляє її привілеї, вона нейтралізує дію команди DENY.
Створення користувача не дає йому ніяких прав на доступ до об'єктів бази даних.
Права доступу надаються командою GRANT. При цьому потрібно пам'ятати, що користувач, який видає команду GRANT, може передати або, якщо вам більше подобається делегувати іншим користувачам тільки ті права, якими він володіє сам.
GRANT визначає права на об'єкти бази даних користувачам, ролям або іншим об'єктам бази даних. Коли об'єкт створюється, права на нього має лише його творець і лише він може надавати права іншим користувачам чи об'єктам.
Для доступу до таблиці або огляду користувач або об'єкт потребує прав на SELECT, INSERT, UPDATE, DELETE або REFERENCES. Усі права можуть бути надані опцією ALL.
Для виклику процедури у програмі користувач повинен мати права на EXECUTE.
Користувачі можуть отримати дозвіл надавати права іншим користувачам передачею прав за списком
Права можуть надаватися всім користувачам опцією PUBLIC на місці списку імен користувачів. Вказівка опції PUBLIC поширюється лише на користувачів, а не на об'єкти бази даних.
Перелік прав наведено у табл. 8.5.
Таблиця 8.5. Перелік прав
Права можуть бути ліквідовані користувачем, який їх видав, через команду REVOKE. Якщо права були видані за допомогою ALL, то й ліквідовані вони можуть лише в режимі ALL, якщо права були видані за допомогою PUBLIC, то й ліквідовані вони можуть бути тільки в режимі PUBLIC.
Синтаксис:
GRANT (all / PRIVILEGES] / LJST_
(tablename/viewname)
TO (
/EXECUTE ON PROCEDURE procname TO
(LIST_
ILJST_rolename TO (PUBLIC
/ LIST_
Таблиця 8.6. Опис синтаксичних елементів GRANT
| Аргумент | Опис |
| privilege | Ім'я наданого права. Допустимі значення: SELECT, DELETE, INSERT, UPDATE, REFERENCES |
| Col | Ім'я стовпця, який видаються права. |
| Tablename | Ім'я існуючої таблиці, на яку поширюються права |
| Viewname | Ім'я існуючого огляду, на який поширюються права |
| Ім'я існуючого об'єкта бази (процедури, огляду, тригера), на який поширюються права | |
| username | Ім'я користувача, якому передаються права |
| WITH GRANT OPTION | Передає права на передачу прав користувачам, переліченим у списку LIST_ |
| rolename | Ім'я існуючої ролі, створеної командою CREATE ROLE |
| Користувач, якому передаються права участі. Список користувачів має бути заданий у isc4.gdb (створений, наприклад, утилітою IBConsole) | |
| GROUP unix_group | Ім'я групи UNIX, заданої в /etc/group |
Наступна команда передає права користувачеві на SELECT та DELETE. Опція WITH GRANT OPTION дає права їх подальшу передачу.
Приклад 8.5
А ця команда дає право на виконання процедури іншій процедурі та користувачеві.
Приклад 8.6
GRANT EXECUTE ON PROCEDURE PAUTHOR TO PROCEDURE PBOOKAUTHOR, MISHA;
В даному випадку передача прав процедурі PBOOKAUTHOR у нашій базі безглузда, оскільки вона просто не використовує процедуру PAUTHOR, але синтаксично вона цілком коректна.
Наступна команда за змістом повністю аналогічна прикладу 8.5., але орієнтована використання впровадженого SQL.
Приклад 8.7 EXEC SQL
GRANT SELECT, DELETE ON TBOOK TO MISHA WITH GRANT OPTION;
Ліквідація прав. Команда REVOKE
REVOKE ліквідує права на доступ до об'єктів бази даних. Права - це дії з об'єктом, які дозволені користувачеві. SQL-права описані у табл. 8.7.
Зауважимо деякі обмеження при використанні команди REVOKE. Ліквідувати права може лише той, хто їх видав. Одному користувачеві можуть бути передані ті самі права на об'єкт бази даних від будь-якого числа різних користувачів. Команда REVOKE спричиняє позбавлення виданих раніше саме цим користувачем прав. Права, видані всім користувачам опцією PUBLIC можуть бути ліквідовані командою REVOKE тільки з опцією PUBLIC. Синтаксис:
REVOKE username / PUBLIC
Наступна команда ліквідує у користувача права видалення з таблиці (див. приклад 8.5, у разі права на читання в нього залишаються).
Приклад 8.8
REVOKE DELETE ON ТВООК FROM MISHA;
А ця команда скасовує право на виконання процедури іншою процедурою та користувачем (див. виділення відповідних прав у прикладі 8.6)
REVOKE .EXECUTE ON PROCEDURE PAUTHOR FROM PROCEDURE PBOOKAUTHOR, MISHA;
У цьому розділі ви навчитеся роботі з привілеями. Як сказано в Главі 2, SQL зазвичай використовується в середовищах, які вимагають розпізнавання користувачів і відмінності між різними користувачами систем. Взагалі, адміністратори баз даних, самі створюють користувачів і дають їм привілеї. З іншого боку користувачі, які створюють таблиці, самі мають права на управління цими таблицями. Привілеї - те, що визначає, чи може вказаний користувач виконати цю команду. Є кілька типів привілеїв, відповідних кількох типів операцій. Привілеї даються і скасовуються двома командами SQL: - GRANT (Допуск) і REVOKE (скасування). Цей розділ покаже вам, як ці команди використовуються.
КОРИСТУВАЧІ
Кожен користувач у середовищі SQL має спеціальне ідентифікаційне ім'я або номер. Термінологія скрізь різна, але ми вибрали (слід ANSI) посилання на них або номер як на Ідентифікатор (ID) доступу. Команда, надіслана в базі даних асоціюється з певним користувачем; або інакше спеціальним Ідентифікатором доступу. Оскільки це відноситься до бази даних SQL, ID дозволу - це ім'я користувача, і SQL може використовувати спеціальне ключове слово USER, яке посилається до Ідентифікатора доступу пов'язаного з поточною командою. Команда інтерпретується та дозволяється (або забороняється) на основі інформації пов'язаної з Ідентифікатором доступу користувача, який подав команду.
РЕЄСТРАЦІЯ
У системах з численними користувачами, є деякий вид процедури входу в систему, яку користувач повинен виконати, щоб отримати доступ до комп'ютерної системи. Ця процедура визначає, який ID доступу буде пов'язаний з поточним користувачем. Зазвичай, кожна людина, яка використовує базу даних, повинна мати свій власний ID доступу і при реєстрації перетворюється на дійсного користувачам. Однак часто користувачі, які мають багато завдань, можуть реєструватися під різними ID доступу, або навпаки один ID доступу може використовуватися кількома користувачами. З погляду SQL немає жодної різниці між цими двома випадками; він сприймає користувача як його ID доступу. SQL база даних може використовувати власну процедуру входу в систему, або вона може дозволити іншій програмі, типу операційної системи(основна програма, яка працює на вашому комп'ютері), обробляти файл реєстрації та отримувати ID доступу з цієї програми. Тим чи іншим способом, але SQL буде мати ID доступу, щоб зв'язати його з вашими діями, а для вас буде мати значення ключове слово USER.
НАДАННЯ ПРИВІЛЕГ
Кожен користувач SQL базі даних має набір привілеїв. Це те, що користувачеві дозволяється робити (можливо це - файл реєстрації, який може розглядатися як мінімальний привілей). Ці привілеї можуть змінюватися з часом - нові додаватися, старі видалятися. Деякі з цих привілеїв визначені в ANSI SQL, але є й додаткові привілеї, які також необхідні. SQL привілеї, як визначено ANSI, не достатні в більшості ситуацій реального життя. З іншого боку, типи привілеїв, які необхідні, можуть видозмінюватися з видом системи, яку ви використовуєте - щодо якої ANSI не може дати жодних рекомендацій. Привілеї, які не є частиною стандарту SQL, можуть використовувати схожий синтаксис і не повністю збігатися зі стандартом.
СТАНДАРТНІ ПРИВІЛЕГІЇ
SQL привілеї певні ANSI - це привілеї об'єкта. Це означає, що користувач має привілей, щоб виконати цю команду тільки на певному об'єкті в базі даних. Очевидно, що привілеї повинні розрізняти ці об'єкти, але система привілею заснована виключно на привілеях об'єкта не може адресувати все, що потрібно SQL, як ми побачимо це пізніше в цьому розділі. Привілеї об'єкта пов'язані одночасно з користувачами та таблицями. Тобто, привілей дається певному користувачеві у зазначеній таблиці, або базової таблиці чи поданні. Ви повинні пам'ятати, що користувач, який створив таблицю (будь-якого виду), є власником цієї таблиці.
Це означає, що користувач має всі привілеї у цій таблиці та може передавати привілеї іншим користувачам у цій таблиці. Привілеї, які можна призначити користувачеві:
SELECT Користувач із цим привілеєм може виконувати запити у таблиці.
INSERT Користувач із цим привілеєм може виконувати команду INSERT у таблиці.
UPDATE Користувач із цим привілеєм може виконувати команду UPDATE на таблиці. Ви можете обмежити цей привілей для певних стовпців таблиці.
DELETE Користувач із цим привілеєм може виконувати команду DELETE у таблиці.
REFERENCES Користувач із цим привілеєм може визначити зовнішній ключ, який використовує один або більше стовпців цієї таблиці як батьківський ключ. Ви можете обмежити цей привілей для певних стовпців. (Дивіться Розділ 19для подробиць щодо зовнішнього ключа та батьківського ключа.)
Крім того, ви зіткнетеся з нестандартними привілеями об'єкта, такими як INDEX (ІНДЕКС), що дає право створювати індекс у таблиці, SYNONYM (СИНОНІМ), що дає право створювати синонім для об'єкта, який буде пояснений в Главі 23, та ALTER (ЗМІНИТИ) дає право виконувати команду ALTER TABLE у таблиці. Механізм SQL призначає користувачам ці привілеї за допомогою команди GRANT.
КОМАНДА GRANT
Дозвольте припустити, що користувач Diane має таблицю Замовників та хоче дозволити користувачеві Adrian виконати запит до неї. Diane має в цьому випадку ввести наступну команду:
GRANT INSERT ON Salespeople TO Diane;
Тепер Adrian може виконати запити до таблиці Замовників. Без інших привілеїв він може тільки вибрати значення; але не може виконати будь-яку дію, яка б впливала на значення в таблиці Замовників (включаючи використання таблиці Замовників як батьківську таблицю зовнішнього ключа, що обмежує зміни, які виконувати зі значенням у таблиці Замовників).
Коли SQL отримує команду GRANT, він перевіряє привілеї користувача подав цю команду, щоб визначити чи припустима команда GRANT. Adrian самостійно не може видати команду. Він також не може надати право SELECT іншому користувачеві: таблиця ще належить Diane (пізніше ми покажемо, як Diane може дати право Adrian надавати SELECT іншим користувачам).
Синтаксис - той самий, що й для надання інших привілеїв. Якщо Adrian – власник таблиці Продавців, то він може дозволити Diane вводити в неї рядки за допомогою наступної пропозиції
GRANT INSERT ON Salespeople TO Diane; Тепер Diane має право поміщати нового продавця до таблиці.
ГРУПИ ПРИВІЛІЙ, ГРУПИ КОРИСТУВАЧІВ
Ви не повинні обмежувати себе наданням одиночного привілею окремому користувачеві командою GRANT. Списки привілеїв або користувачів, що відокремлюються комами, є цілком прийнятними. Stephen може надати і SELECT та INSERT у таблиці Порядків для Adrian
GRANT SELECT, INSERT ON Orders TO Adrian; або для Adrian і для Diane GRANT SELECT, INSERT ON Orders TO Adrian, Diane;
Коли привілеї та користувачі перераховані таким чином, весь список привілеїв надаються всім вказаним користувачам. У суворій ANSI інтерпретації, ви не можете надати привілеї в багатьох таблицях відразу однією командою, але в деяких реалізаціях це обмеження може бути ослаблене, дозволяючи вам вказувати кілька таблиць, відокремлюючи їх комами, так що весь список привілеїв міг бути наданий для всіх зазначених таблиць .
ОБМЕЖЕННЯ ПРИВІЛЕЙ НА ВИЗНАЧЕНІ СТОЛБЦІ
Усі привілеї об'єкта використовують той самий синтаксис, крім команд UPDATE і REGERNCES у яких необов'язково вказувати імена стовпців. Привілей UPDATE можна надавати на зразок інших привілеїв:
GRANT UPDATE ON Salespeople TO Diane;
Ця команда дозволить Diane змінювати значення у будь-якому чи у всіх стовпцях таблиці Продавців. Однак, якщо Adrian хоче обмежити Diane у зміні наприклад комісійних, він може ввести
GRANT UPDATE (comm) ON Salespeople TO Diane;
Іншими словами, він просто повинен вказати конкретний стовпець, до якого привілей UPDATE повинен бути застосований у круглих дужках після імені таблиці. Імена численних стовпців таблиці можуть вказуватися в будь-якому порядку, що відокремлюються комами:
GRANT UPDATE (city, comm) ON Salespeople TO Diane;
REFERENCES дотримується того самого правила. Коли ви надасте привілей REFERENCES іншому користувачеві, він зможе створювати зовнішні ключі, які посилаються на стовпці вашої таблиці, як на батьківські ключі. Подібно до UPDATE, для привілею REFERENCES може бути вказаний список з одного або більше стовпців для яких обмежений цей привілей. Наприклад, Diane може надати Stephen право використовувати таблицю Замовників як таблицю батьківського ключа за допомогою такої команди:
GRANT REFERENCES (cname, cnum) ON Customers TO Stephen; Ця команда дає Stephen право використовувати стовпці cnum і cname як батьківські ключі по відношенню до будь-яких зовнішніх ключів у його таблицях. Stephen може контролювати те, як це буде виконано. Він може визначити (cname, cnum) або, як у нашому випадку (cnum, cname), як дво-стовпцевий батьківський ключ, що збігається за допомогою зовнішнього ключа з двома шпальтами в одній з його власних таблиць. Або він може створити окремі зовнішні ключі, щоб посилатися на підлогу індивідуально, забезпечивши таким чином, щоб Diane мала примусове присвоєння батьківського ключа (див. Розділ 19).
Не маючи обмежень на номери зовнішніх ключів, він повинен базуватися на цих батьківських ключах, а батьківські ключі різних зовнішніх ключів дозволені для суміщення (overlap).
Як і у випадку з привілеєм UPDATE, ви можете виключити список стовпців і таким чином дозволяти всім без винятку стовпцям бути використаними як батьківські ключі. Adrian може надати Diane право зробити це наступною командою:
GRANT REFERENCES ON Salespeople TO Diane;
Звичайно, привілей буде придатний для використання тільки в стовпцях, які мають обмеження, необхідні для батьківських ключів.
ВИКОРИСТАННЯ АРГУМЕНТІВ ALL І PUBLIC
SQL підтримує два аргументи для команди GRANT, які мають спеціальне значення: ALL PRIVILEGES (ВСЕ ПРИВІЛЕЇ) або просто ALL і PUBLIC (ЗАГАЛЬНІ). ALL використовується замість імен привілеїв у команді GRANT щоб віддати всі привілеї у таблиці. Наприклад, Diane може дати Stephen весь набір привілеїв у таблиці Замовників за допомогою такої команди:
GRANT REFERENCES ON Salespeople TO Diane;
(Привілеї UPDATE і REFERENCES природно застосовуються до всіх стовпців.) А це інший спосіб висловити ту ж думку:
GRANT ALL ON Customers TO Stephen;
PUBLIC - більше схожий на тип аргументу - захопити все (catch-all), ніж на привілей користувача. Коли ви надаєте привілеї для публікації, всі користувачі їх автоматично отримують. Найчастіше це застосовується для привілею SELECT в певних базових таблицях або уявленнях, які ви хочете зробити доступними для будь-якого користувача. Щоб дозволити будь-якому користувачеві бачити таблицю Порядків, ви, наприклад, можете ввести таке:
GRANT SELECT ON Orders TO PUBLIC;
Звичайно, ви можете надати будь-які чи всі привілеї суспільству, але це мабуть небажано. Всі привілеї, за винятком SELECT, дозволяють користувачеві змінювати (або, у випадку REFERENCES, обмежувати) зміст таблиці. Дозвіл усім користувачам змінювати зміст таблиць викликає проблему.
Навіть якщо ви маєте невелику компанію, і в ній працюють усі ваші поточні користувачі здатні виконувати команди модифікації в даній таблиці, було б краще надати привілеї кожному користувачеві індивідуально, ніж ті самі привілеї для всіх. PUBLIC не обмежений у передачі лише поточним користувачам. Будь-який Новий користувачдоданий до вашої системи, автоматично отримає всі привілеї призначені раніше всім, так що якщо ви захочете обмежити доступ до таблиці всім, зараз чи в майбутньому, найкраще надати інші привілеї ніж SELECT для індивідуальних користувачів.
НАДАННЯ ПРИВІЛЕЙ ЗА ДОПОМОГОЮ WITH GRANT OPTION
Іноді, творцю таблиці хочеться, щоб інші користувачі могли отримати привілеї в його таблиці. Зазвичай це робиться в системах, де один або більше людей створюють декілька (або всі) базові таблиці в базі даних, а потім передають відповідальність за них тим, хто буде фактично з ними працювати. SQL дозволяє робити це за допомогою пропозиції WITH GRANT OPTION. Якщо Diane хотіла б, щоб Adrian мав право надавати привілей SELECT у таблиці Замовників іншим користувачам, вона дала б йому привілей SELECT з використанням пропозиції WITH GRANT OPTION:
GRANT SELECT ON Customers TO Adrian WITH GRANT OPTION; Після цього Adrian отримав право передавати привілей SELECT третім особам; може видати команду GRANT SELECT ON Diane.Customers TO Stephen; або навіть GRANT SELECT ON Diane.Customers TO Stephen WITH GRANT OPTION; Користувач за допомогою GRANT OPTION в особливому привілеї для даної таблиці, може, у свою чергу, надати цей привілей до тієї ж таблиці, з або без GRANT OPTION, будь-якому іншому користувачеві. Не змінює приналежності самої таблиці; як і раніше, таблиця належать її творцю. (Тому користувачі, які отримали права, повинні встановлювати префікс ID доступу власника, коли посилаються до цих таблиць. Наступний розділ покаже вам цей спосіб.) Користувач же за допомогою GRANT OPTION у всіх привілеях для даної таблиці матиме всю повноту влади в тій таблиці.
Скасування привілеїв
Також як ANSI надає команду CREATE TABLE щоб створити таблицю, а не DROP TABLE щоб її позбутися, так і команда GRANT дозволяє вам давати привілеї користувачам, не надаючи способу відібрати їх назад. Потреба видаляти привілеї зводиться до REVOKE, фактично стандартному засобу з досить зрозумілою формою запису. Синтаксис команди REVOKE – схожий на GRANT, але має зворотний глузд. Щоб видалити привілей INSERT для Adrian у таблиці Порядків, можна ввести
REVOKE INSERT ON Orders FROM Adrian;
Використання списків привілеїв та користувачів тут допустимі як і у випадку з GRANT, тому ви можете ввести наступну команду:
REVOKE INSERT, DELETE ON Customers FROM Adrian, Stephen; Однак тут є деяка неясність. Хто має право скасовувати привілеї? Коли користувач із правом передавати привілеї іншим, втрачає це право? Користувачі, яким він надав ці привілеї, також їх втратять? Так як це не стандартна особливість, немає жодних авторитетних відповідей на ці питання, але найбільш загальний підхід - це такий: * Привілеї скасовуються користувачем, який їх надав, і скасування буде каскадуватися, тобто вона автоматично поширюватиметься на всіх користувачах, що отримали від нього цей привілей. .
ВИКОРИСТАННЯ ПРЕДСТАВ ДЛЯ ФІЛЬТРАЦІЇ ПРИВІЛІЙ
Ви можете зробити дії привілеїв більш точними, використовуючи уявлення. Щоразу, коли ви передаєте привілей у базовій таблиці користувачеві, вона автоматично поширюється попри всі рядки, а за використанні можливих винятків UPDATE і REFERENCES, попри всі стовпці таблиці. Створюючи уявлення, яке посилається на основну таблицю і потім переносить привілей на подання, а не на таблицю, ви можете обмежувати ці привілеї будь-якими виразами в запиті, що міститься у поданні. Це значно покращує базові можливості команди GRANT.
Хто може створювати уявлення?
Щоб створювати уявлення, ви повинні мати привілей SELECT у всіх таблицях, на які ви посилаєтеся у поданні. Якщо уявлення - модифіковане, будь-який привілей INSERT, UPDATE, і DELETE, які ви маєте в базовій таблиці, автоматично передаватиметься уявленню. Якщо ви відчуваєте недолік у привілеях на модифікацію в базових таблицях, ви не зможете мати їх і в уявленнях, які створили, навіть якщо самі ці уявлення - модифіковані. Так як зовнішні ключі не використовуються в уявленнях, привілей REFERENCES ніколи не використовується для створення уявлень. Всі ці обмеження визначаються ANSI. Нестандартні привілеї системи (що обговорюються пізніше в цьому розділі) також можуть бути включені. У наступних розділах ми припустимо, що творці уявлень, які ми обговорюємо, мають приватні або відповідні привілеї у всіх базових таблицях.
ОБМЕЖЕННЯ ПРИВІЛЕГІЇ SELECT ДЛЯ ВИЗНАЧЕНИХ СТУПНИКІВ
Припустимо ви хочете дати користувачеві Claire здатність бачити тільки стовпці snum та sname таблиці Продавців. Ви можете зробити це, помістивши імена цих стовпців у виставу
CREATE VIEW Clairesview AS SELECT snum, sname FROM Salespeople; та надати Claire привілей SELECT у поданні, а не в самій таблиці Продавців: GRANT SELECT On Clairesview to Claire; Ви можете створити привілеї спеціально для стовпців на зразок використання інших привілеїв, але, для команди INSERT, це означатиме вставку значень за замовчуванням, а для команди DELETE, обмеження стовпця не матиме значення. Привілеї REFERENCES і UPDATE, звичайно, можуть зробити стовпці специфічними, не вдаючись до подання.
ОБМЕЖЕННЯ ПРИВІЛІЙ ДЛЯ ВИЗНАЧЕНИХ РЯДКІВЗазвичай, більш корисний спосіб, щоб фільтрувати привілеї з уявленнями - це використовувати уявлення, щоб привілей ставився тільки до певних рядків. Ви робите це, природно, використовуючи предикат у поданні який визначить, які рядки включені. Щоб надати користувачеві Adrian, привілей UPDATE у таблиці Замовників, для всіх замовників розміщених у Лондоні, ви можете створити таке уявлення:
CREATE VIEW Londoncust AS SELECT * FROM Customers WHERE city = "London" WITH CHECK OPTION; Потім Ви повинні передати привілей UPDATE у цій таблиці для Adrian: GRANT UPDATE ON Londoncust TO Adrian; У цьому відмінність привілею для певних рядків від привілею UPDATE для певних стовпців, яка поширена на всі стовпці таблиці Замовників, але не на рядки, серед яких рядки зі значенням пів city іншим, ніж London, не враховуватимуться. Пропозиція WITH CHECK OPTION оберігає Adrian від заміни значення стать city на будь-яке значення крім London. НАДАННЯ ДОСТУПУ ТІЛЬКИ ДО ВИНЯТИЙ ДАНИХІнша можливість полягає в тому, щоб пропонувати користувачам доступ до вже отриманих даних, а не фактичних значення в таблиці. Агрегатні функції можуть бути дуже зручними у застосуванні такого способу. Ви можете створювати уявлення, яке дає рахунок, середню, і загальну кількість для порядків на кожен день порядку: CREATE VIEW Datetotals Тепер ви передаєте користувачеві Diane - привілей SELECT у поданні Datetotals: GRANT SELECT ON Datetotals TO Diane; ВИКОРИСТАННЯ ПРЕДСТАВ У ЯКОСТІ АЛЬТЕРНАТИВИ ДО ОБМЕЖЕНЬОднією з останніх прикладних програміз серії, описаної в Розділ 18, є використання уявлень з WITH CHECK OPTION як альтернативи обмеженням. Припустимо, що ви хотіли переконатися, що всі значення пів city в таблиці Продавців знаходяться в одному з міст де ваша компанія в даний час має відомство. Ви можете встановити обмеження CHECK безпосередньо на стовпець city, але пізніше може стати важко його змінити, якщо ваша компанія, наприклад, відкриє там інші відомства. В якості альтернативи, можна створити уявлення, яке виключає неправильні значення city: CREATE VIEW Curcities AS SELECT * FROM Salespeople WHERE city IN ("London", "Rome", "San Jose", "Berlin") WITH CHECK OPTION; Тепер замість того, щоб надати користувачам привілеї модифікування в таблиці Продавців, ви можете надати їх у поданні Curcities. Перевага такого підходу - в тому, що якщо вам потрібно зробити зміну, ви можете видалити це уявлення, створити нове, і надати в цьому новому поданні привілею користувачам, що простіше, ніж змінювати обмеження. Недоліком є те, що власник таблиці Продавців також повинен використовувати це подання, якщо він не хоче, щоб його власні команди були відхилені. З іншого боку, цей підхід дозволяє власнику таблиці та будь-яким іншим отримати привілеї модифікації у самій таблиці, а не у поданні, щоб робити винятки для обмежень.
Це часто буває бажано, але не можна здійснити, якщо ви використовуєте обмеження в базовій таблиці. На жаль, ці винятки не можна буде побачити у виставі. Якщо ви оберете цей підхід, вам захочеться створити друге уявлення, що містить лише винятки: CREATE VIEW Othercities AS SELECT * FROM Salespeople WHERE city NOT IN ("London", "Rome", "San Jose", "Berlin") WITH CHECK OPTION; Ви повинні вибрати для передачі користувачам лише привілей SELECT у цьому поданні, щоб вони могли бачити виключені рядки, але не могли поміщати неприпустимі значення city у базову таблицю. Фактично користувачі могли б зробити запит обох уявлень в об'єднанні і побачити всі рядки відразу.
ІНШІ ТИПИ ПРИВІЛЕЙ
Ви зрозуміло хочете знати, хто має право першим створити таблицю. Ця область привілею не відноситься до ANSI, але не може ігнорувати. Усі стандартні привілеї ANSI випливають із цього привілею; привілеї авторів таблиць які можуть передавати привілеї об'єкта. Якщо всі ваші користувачі будуть створювати в системі базові таблиці з різними розмірамице призведе до надмірності в них та до неефективності системи. Притягують до себе та інші питання:Хто має право змінювати, видаляти чи обмежувати таблиці?
Чи мають права створення базових таблиць відрізнятися від прав створення уявлень?
Чи має бути суперкористувач - користувач, який відповідає за підтримку бази даних і, отже, має найбільші, або всі привілеї, які не надаються індивідуально?
Поки ANSI не бере участі в цьому, а SQL використовується в різних середовищах, ми не можемо дати остаточної відповіді на ці питання. Ми пропонуємо розглянути тут шмат найбільш загальних висновків.
Привілеї, які не визначаються в термінах спеціальних об'єктів даних, називаються привілеями системи, або правами бази даних. На базисному рівні, вони ймовірно включатимуть право створювати об'єкти даних, ймовірно відрізняються від базових таблиць (зазвичай створюваними кількома користувачами) і уявлення (зазвичай створювані більшістю користувачів). Привілеї системи для створення уявлень повинні доповнювати, а не замінювати привілеї об'єкта, які ANSI вимагає від творців уявлень (описаних раніше в цьому розділі). Крім того, в системі будь-якого розміру завжди є деякі типи суперкористувачів - користувачів, які автоматично мають більшість або всі привілеї - і які можуть передати свій статус суперкористувача комусь за допомогою привілею або групи привілеїв. Адміністратор Бази Даних, або DBA, є терміном, що найчастіше використовується для такого суперкористувача, і для привілеїв якими він володіє.
ТИПОВІ ПРИВІЛЕЇ СИСТЕМИ
При загальному підході є три базові привілеї системи: - CONNECT (Підключити), - RESOURCE (Ресурс), і - DBA (Адміністратор Бази Даних). Простіше, можна сказати, що CONNECT складається з права зареєструватися та права створювати уявлення та синоніми (див. Главу 23), якщо передані привілеї об'єкта. RESOURCE складається із права створювати базові таблиці. DBA - це привілей суперкористувача, що дає користувачеві високі повноваження у базі даних. Один або більше користувачів з функціями адміністратора бази даних може мати цей привілей. Деякі системи також мають спеціального користувача, іноді званого SYSADM або SYS ( Системний адміністраторбази даних), який має найвищі повноваження; це - спеціальне їм, а не просто користувач із спеціальним DBA привілеєм. Фактично лише одна людина має право зареєструватися з ім'ям SYSADM, що є його ідентифікатором доступу. Відмінність дуже тонка і функціонує по-різному в різних системах. Для наших цілей, ми будемо посилатися на високопривілейованого користувача, який розробляє і управляє базою даних маючи повноваження DBA, розуміючи що фактично ці повноваження - той самий привілей. Команда GRANT, у зміненій формі, є придатною для використання з привілеями об'єкта як і системними привілеями. Спочатку передача прав може бути зроблено за допомогою DBA. Наприклад, DBA може передати привілей для створення таблиці користувачеві Rodriguez таким чином: GRANT RESOURCE TO Rodriguez;СТВОРЕННЯ І ВИДАЛЕННЯ КОРИСТУВАЧІВ
Природно постає питання, звідки візьметься користувач з ім'ям Rodriguez? Як визначити його ID допуску? У більшості реалізацій DBA створює користувача, автоматично надаючи йому привілей CONNECT. У цьому випадку зазвичай додається пропозиція IDENTIFIED BY, що вказує пароль. (Якщо ж, операційна система повинна визначити, чи можете ви зареєструватися в базі даних з даними ID доступу.) DBA може, наприклад, ввести GRANT CONNECT TO Thelonius IDENTIFIED BY Redwagon; що приведе до створення користувача, з ім'ям Thelonius, надасть йому право реєструватися, і призначить йому пароль Redwagon, і все це в одному реченні. Якщо Thelonious - вже впізнаний користувач, він або DBA можуть використовувати цю ж команду, щоб змінити пароль Redwagon. Хоча це і зручно, але все ж таки є обмеження і в цьому підході. Це неможливість мати користувача який не міг би зареєструватись, хоча б тимчасово. Якщо ви хочете заборонити користувачеві реєструватися, ви повинні використовувати для REVOKE привілей CONNECT, який "вилучає" цього користувача. Деякі реалізації дозволяють створювати та видаляти користувачів, незалежно від їх привілеїв при реєстрації. Коли ви надаєте привілей CONNECT користувачу, ви створюєте цього користувача. При цьому, щоб зробити це Ви самі, повинні мати DBA привілей. Якщо цей користувач буде створювати базові таблиці (а не лише уявлення), йому потрібно також надати привілей RESOURCE. Але це одразу породжує іншу проблему. Якщо ви спробуєте видалити привілей CONNECT користувача, який має ним створені таблиці, команда буде відхилена, тому що її дія залишить таблицю без власника, а це не дозволяється. Ви повинні спочатку видалити всі таблиці, створені цим користувачем, перш ніж видалити його привілей CONNECT . Якщо ці таблиці не порожні, то ви, можливо, захочете передати їх дані в інші таблиці за допомогою команди INSERT, яка використовує запит. Вам не потрібно видаляти окремо привілей RESOURSE; достатньо видалити CONNECT, щоб видалити користувача. Хоча все вище сказане - це цілком стандартний підхід до привілеїв системи, він також має значні обмеження. З'явилися альтернативні підходи, які більш конкретно визначені та точніше керують привілеями системи.Ці висновки дещо виводять нас за межі стандарту SQL, як це визначено в даний час, і, в деяких реалізаціях, можуть повністю вийти за межі стандарту SQL. Ці речі, ймовірно, не будуть вас дуже торкатися, якщо ви не DBA або не користувач високого рівня. Звичайні користувачі просто повинні бути знайомими з привілеями системи в принципі, справляючись зі своєю документацією лише у разі спеціальних повідомлень.
РЕЗЮМЕ
Привілеї дають можливість бачити SQL під новим кутом зору, коли SQL виконує дії через спеціальних користувачів у спеціальній системі бази даних. Сама команда GRANT досить проста: за її допомогою ви надаєте ті чи інші привілеї об'єкта одному або більше користувачам. Якщо ви надаєте привілей WITH GRANT OPTION користувачеві, цей користувач може в свою чергу надати цей привілей іншим. Тепер ви розумієте натяки на використання привілеїв у уявленнях - щоб удосконалити привілеї в базових таблицях, або як альтернативи до обмежень - і на деякі переваги та недоліки такого підходу. Привілеї системи, які необхідні, але не входять в область стандарту SQL, обговорювалися в їхній найбільш загальній формі і тому ви будете знайомитися з ними на практиці. Розділ 23продовжить обговорення про висновки в SQL, таких як збереження або відновлення змін, створення ваших власних імен для таблиць, що належать іншим людям, і розуміння, що відбувається коли різні користувачі намагаються звертатися до одного і того ж об'єкта одночасно.РОБОТА З SQL
1. Передайте Janet право на зміну оцінки замовника.2. Передайте Stephan право передавати іншим користувачам право робити запити у таблиці Порядків.
3. Відніміть привілей INSERT(ВСТАВКА) у таблиці Продавців у Claire та у всіх користувачів яким вона була надана.
4. Передайте Jerry право вставляти або модифікувати таблицю Замовників зі збереженням можливості оцінювати значення в діапазоні від 100 до 500.
5. Дозвольте Janet робити запити у таблиці Замовників, але забороніть йому зменшувати оцінки у тій же таблиці Замовників.
Команди DCL використовуються для безпеки баз даних у середовищі з кількома базами даних користувача. Два типи команд DCL є надавати та відкликати. Тільки адміністратор бази даних або власник об'єкта бази даних може надати / видалити привілеї на об'єкт бази даних.
SQL GRANT Command
SQL GRANT є команда, що використовується для надання доступу або привілеї на об'єкти бази даних для користувачів.
Синтаксис команди GRANT є:
GRANT privilege_name
ON object_name
TO (user_name |PUBLIC |role_name)
;
- PRIVILEGE_NAME це право доступу або привілей надається користувачеві. Деякі права доступу, ALL, ВИКОНАТИ і SELECT.
- object_name це ім'я об'єкта бази даних, як таблиці, уявлення, і процедура послідовності, що зберігається.
- user_name
- user_name це ім'я користувача, якому доступ право бути само собою зрозуміле.
- ГРОМАДСЬКЕ використовується для надання прав доступу всім користувачам.
- РОЛІ являють собою набір привілеїв згруповані разом.
- WITH GRANT OPTION - Дозволяє користувачеві надати право доступу іншим користувачам.
Наприклад:Співробітник ГРАНТ НА ВИБІР ДЛЯ user1; Ця команда надає дозвіл SELECT, на столі співробітника на user1.You слід використовувати з опцією GRANT обережно, тому що, наприклад, якщо ви надасте SELECT, привілей на таблиці співробітників до user1, використовуючи опцію WITH GRANT, то user1 може надати привілей SELECT, таблиці співробітника до іншого користувача, такі як user2 і т.д. Пізніше, якщо ви відкликати привілей SELECT, працівник від user1, як і раніше user2 буде мати привілей SELECT, таблиці співробітників.
SQL REVOKE Команда:
Команда REVOKE видаляє права користувача доступу або привілеї для об'єктів бази даних.
Синтаксис команди REVOKE є:
REVOKE privilege_name
ON object_name
FROM (user_name |PUBLIC |role_name)
Наприклад:КЕУОКЕ ВИБРАТИ ВКЛ співробітнику user1; Ця команда буде відкликати SELECT, привілей на столі співробітника з user1.When ви REVOKE SELECT, привілей на столі від користувача, користувач не зможе більше вибору даних із цієї таблиці. Тим не менш, якщо користувач отримав привілеї SELECT, на цьому столі з більш ніж одного користувачів, він / вона може вибрати з цієї таблиці, поки кожен, хто отримав дозвіл, не відкликає його. Ви не можете відкликати привілеї, якщо вони спочатку не були надані Вами.
Привілеї та Ролі:
Привілеї: Права доступу визначає права доступу, що надаються користувачеві на об'єкт бази даних. Є два типи привілеїв.
привілеї 1) Системні- Це дозволяє користувачеві створювати, змінювати чи видаляти об'єкти бази даних.
2) Привілеї об'єктів- Це дозволяє користувачеві ВИКОНАТИ, SELECT, INSERT, UPDATE або DELETE дані з об'єктів бази даних, до яких застосовуються пільги.
Мало створити системні привілеї, наведені нижче:
| System Privileges | Description |
|---|---|
| CREATE object | дозволяє користувачам створити особливий об'єкт у їхній власній системі. |
| CREATE ANY object | дозволяє користувачам створити особливий об'єкт в будь-який час. |
Вищезгадані правила також застосовуються для Альтера та DROP системні привілеї.
Мало хто з привілеїв об'єктів перераховано нижче:
| Object Privileges | Description |
|---|---|
| INSERT | дозволяють користувачам до insert rows в table. |
| SELECT | дозволяє користувачам виділити data від database object. |
| UPDATE | allows user to update data в таблиці. |
| EXECUTE | дозволяє користувачеві execute a stored procedure або function. |
Ролі:Ролі є набір привілеїв або прав доступу. Коли багато користувачів у базі даних стає важко надавати або скасовувати привілеї для користувачів. Тому, якщо ви визначили ролі, ви можете надати або скасувати привілеї для користувачів, тим самим автоматично надавати або скасувати пільги. Ви можете створювати ролі або використовувати системні ролі визначених оракула.
Деякі з привілеїв, наданих системних ролей, як зазначено нижче:
| System Role | Privileges Granted to the Role |
|---|---|
| CONNECT | CREATE TABLE, CREATE VIEW, CREATE SYNONYM, CREATE SEQUENCE, CREATE SESSION etc. |
| RESOURCE | CREATE PROCEDURE, CREATE SEQUENCE, CREATE TABLE, CREATE TRIGGER etc. У першу чергу використання інструмента RESOURCE є обмеженим доступом до данихоб'єктів. |
| DBA | ALL SYSTEM PRIVILEGES |
Створення ролей:
Синтаксис для створення ролі:
CREATE ROLE role_name
;
Наприклад:Щоб створити роль під назвою "розробник" з паролем як "PWD", код виглядатиме таким чином
CREATE ROLE testing
;
Це легше надавати або скасовувати привілеї для користувачів через ролі, а не надання привілеїв безпосередньо кожному користувачеві. Якщо роль ідентифікується за допомогою пароля, а потім, коли ви надати або скасувати привілеї для ролі, ви повинні ідентифікувати його з паролем.
Ми можемо надати або скасувати привілей ролі, як показано нижче.
Наприклад:Щоб надати привілей CREATE TABLE користувачу за допомогою ролі тестування:
По-перше, створити тестування ролі
CREATE ROLE testing
По-друге, надати привілей CREATE TABLE для тестування ролі. Ви можете додати додаткові привілеї для цієї ролі.
GRANT CREATE TABLE TO testing;
По-третє, надати користувачеві роль.
GRANT testing TO user1;
Щоб скасувати привілей CREATE TABLE від тестування РОЛІ, ви можете написати:
REVOKE CREATE TABLE FROM testing;
Синтаксис упустити роль з бази даних, як показано нижче:
DROP ROLE role_name;
Наприклад:Щоб видалити роль під назвою розробник, можна написати.
Повний опис сервісу стрімінгу
Як створити гаманець WebMoney Детальна інструкція з реєстрації webmoney
Програма для оптимізації та прискорення Windows
Збільшення кешу в браузері Як збільшити кеш в мозилі
Як надіслати файл або папку електронною поштою
Драйвер для Wi-Fi та LAN для ноутбука Acer
Зареєструвати вконтакті нову сторінку