Главная | Обратная связь | Поможем написать вашу работу!

Створення, видалення і оновлення привілей

Отже. SQL призначає користувачам ці привілеї за допомогою команди GRANT. Наприклад, якщо користувач SA володіє таблицею студентів STUDENTS і бажає дозволити користувачу SHER виконати запит до неї. то SA повинен в цьому випадку виконати наступну команду:

GRANT SELECT ON STUDENTS TO SHER;

Тепер SHER може виконувати запити до таблиці STUDENTS без інших привілеїв, тобто він може тільки вибрати значення, але не може виконати будь-яку дію, яка б впливала на значення в таблиці, включаючи використовування її в якості батьківської таблиці зовнішнього ключа.

Коли SQL одержує команду GRANT, він перевіряє привілеї користувача, що подав її. і визначає її допустимість. При цьому SHER самостійно не може виконати цю команд або надати право SELECT іншому користувачу, таблиця йому не належить. Якщо ж для користувача SHER необхідно надати право вставляти в таблицю рядка, то це можна реалізувати за допомогою наступної пропозиції:

GRANT INSERT ON STUDENTS TO SHER;

Проте часто доводиться передавати декілька привілеїв окремому користувачу командою GRANT. Тоді списки привілеїв або користувачів в команді відділяють комами. Наприклад, з ціллю надання привілеїв для запиту і вставки значень користувачам SHER і MAG в таблиці STUDENTS, можна скористатися командою:

GRANT SELECT, INSERT ON STUDENTS TO SHER, MAG;

Коли привілеї і користувачі перераховані таким чином, як показано вище, весь список привілеїв надаються всім вказаним користувачам. В деяких СУБД, крім цього, припускає через кому перерахувати список таблиць, до яких застосовуються привілеї для всіх вказаних користувачів.

Всі привілеї об'єкту використовують один і той же синтаксис, окрім команд UPDATE і REFERENCES, в яких можна додатково указувати імена полів. Наприклад, команда.

GRANT UPDATE ON STUDENTS TO SHER; дозволить SHER змінювати значення у всіх полях таблиці STUDENTS. Проте власник може обмежити його в зміні таблиці, наприклад, вводячи таку команду:

GRANT UPDATE (STIP) ON STUDENTS TO SHER;

дозволяючи модифікувати тільки поле STIP. Іншими словами, можна просто вказати конкретне поле, до якого привілей UPDATE повинен бути застосована. При цьому припускають списки з декількох, вказаних в довільному порядку, стовців таблиці, до яких встановлюваний привілей повинен бути застосована, наприклад:

GRANT UPDATE (SFAM, STIP) ON STUDENTS TO SHER;

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

Подібно UPDATE, для привілею REFERENCES може бути вказаний список з одного або більш стовпців, для яких призначений цей привілей. Наприклад, можна надати SHER право використати STUDENTS, як таблицю батьківського ключа, за допомогою наступної команди:

GRANT REFERENCES (SNUM, STIP) ON STUDENTS TO SHER;

Ця команда дає SHER право використати поля SNUM. STIP в якості батьківських ключів по відношенню до будь-яких зовнішніх ключів в його таблицях. Як і у випадку з привілеєм UPDATE, тут можна виключати список полів і, таким чином, дозволяти всім без виключення стовпцям бути використовуваними в якості батьківських ключів, що здійснюється за допомогою команди:

GRANT REFERENCES ON STUDENTS TO SHER;

Природно, що привілей буде придатна для використовування тільки в тих полях, які мають обмеження, необхідні для батьківських ключів. SQL підтримує два аргументи для команди GRANT, які мають спеціальне значення - це ALL PRIVILEGES (або ALL) і PUBLIC.

ALL використовується замість імен привілеїв в команді GRANT для того, щоб віддати всі привілеї в таблиці. Наприклад, для передачі користувачу SHER всього набору привілеїв для таблиці STUDENTS можна скористатися наступною командою:

GRANT ALL ON STUDENTS TO SHER

Привілеї PUBLIC більше схожі на тип аргументу для таблиці - коли вона надається, всі користувачі її одержують автоматично. Найбільш часто це застосовується для привілею SELECT в певних базових таблицях або представленнях, які необхідно зробити доступними для будь-якого користувача. Наприклад, для того, щоб дозволити будь-якому користувачу переглядати таблицю STUDENTS, необхідно виконати наступне:

GRANT SELECT ON STUDENTS TO PUBLIC

Звичайно, можна надати любі або навіть всі привілеї будь-якому користувачу, але це небажано, т.к. всі привілеї, за винятком SELECT, дозволяють змінювати або обмежувати зміст таблиці, а це може викликати проблеми. Майте на увазі, що будь-який новий користувач, що додається до системи, автоматично одержує всі привілеї, призначені як PUBLIC.

Іноді при створенні таблиці виникає необхідність в тому. щоб інші користувачі могли одержувати і передавати привілеї в таблиці. SQL дозволяє робити це за допомогою команди WITH GRANT OPTION. Наприклад, якщо SA бажає, щоб SHER мав право надавати привілей SELECT в таблиці STUDENTS іншим користувачам, це можна реалізувати таким чином:

GRANT SELECT ON STUDENTS TO SHER WITH GRANT OPTION/

Після цього SHER одержує право передавати привілей SELECT третім особам, наприклад, він може використати такі команди:

GRANT SELECT ON STUDENTS TO MAG або

GRANT SELECT ON STUDENTS TO MAG WITH GRANT OPTION

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

При виникненні потреби у видаленні привілею, використовується команда REVOKE. Синтаксис команди REVOKE схожий на GRANT, але має зворотний сенс. Наприклад, щоб видалити привілей INSERT для SHER в таблиці STUDENTS, можна ввести:

REVOKE INSERT ON STUDENTS FROM SHER

Використовування списків привілеїв і користувачів тут допустимі, як і у випадку з GRANT. Тому дозволяється ввести команду, яка відмінить привілеї на видалення і вставку для користувачів SHER і MAG:

REVOKE DELETE, INSERT ON STUDENTS TO SHER, MAG

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

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

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

Припустимо, що необхідно користувачу SHER надати можливість переглядати тільки поля SNUM і SFAM таблиці STUDENTS. Це реалізується шляхом створення представлення

CREATE VIEW TEST

AS SELECT SNUM, SFAM FROM STUDENTS

а потім надання користувачу SHER привілею SELECT в уявленні, а не в самій таблиці, тобто

GRANT SELECT ON TEST TO SHER;

Можна створити привілеї спеціально для полів команд модифікації. Проте треба пам'ятати, що для інших полів таблиці в команді INSERT це буде означати вставку значень за умовчанням, а для команди DELETE - обмеження стовпця не буде мати значень.

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

Наприклад, щоб надати користувачу SHER привілей UPDATE в таблиці STUDENTS, але так, що модифікуватися можуть дані для студентів з нульовою стипендією, створюється таке представление'

CREATE VIEW NULLSTIP

AS SELECT *

FROM STUDENTS

WHERE STIP = 0

WITH CHECK OPTION;

а потім - передається привілей UPDATE:

GRANT UPDATE ON NULLSTIP TO SHER;

В цьому полягає відмінність привілею для певних рядків від привілею UPDATE для деяких стовпців, яка поширена на всі стовпці таблиці. Фраза WITH CHECK OPTION оберігає SHER від заміни значення поля STIP на будь-яке значення, окрім 0.

Інша можливість полягає в тому, щоб пропонувати користувачам доступ до даних, що вже витягають, а не до фактичних значень в таблиці. В даному випадку зручно скористатися агрегатними функціями. Наприклад, можна створити представлення, яке виводить середнє значення оцінок кожного студента:

CREATE VIEW AVGNUM

AS SELECT SNUM, AVG(OCENKA)

FROM USP

GROUP BY SNUM;

і потом передати користувачу SHER привілей SELECT в уявленні AVGNUM:

GRANT SELECT ON AVGNUM TO SHER;

До речі, альтернативою обмеження є використовування уявлень з WITH CHECK OPTION. Наприклад, можна створити наступне представлення для введення оцінок в таблицю успішності:

CREATE VIEW INPOC AS SELECT *

FROM USP

WHERE OCENKA IN (1, 2, 3, 4, 5)

WITH CHECK OPTION;

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

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

Системні привілеї

Не варто забувати, що в системі завжди є деякі типи користувачів, які автоматично мають більшість або навіть всі привілеї, а також мають можливість передати свій статус кому-небудь за допомогою привілею або групи привілеїв. Зокрема, таким користувачем є адміністратор БД.

В самому загальному випадку є три базового привілею системи:

•

• CONNECT - складається з права реєструватися і права створювати представлення і синоніми, якщо користувачу передані відповідні привілеї об'єкту;
• RESOURCE - складається з права створювати базові таблиці;
• DBA - це привілей користувача, що дає найвищі повноваження в БД

Деякі системи, крім того, мають спеціального користувача, іноді званого SYSADM. SYS або SA, який має щонайвищі повноваження. Фактично це - спеціальне ім'я. а не просто користувач з особливим DBA привілеєм. Бажано, щоб тільки одна людина мала право реєструватися з ім'ям SA.

Команда GRANT є придатною для використовування як з привілеями об'єкту, так і з системними привілеями. Наприклад, адміністратор БД може передати привілей для створення таблиці користувачу SHER таким чином:

GRANT RESOURCE TO SHER;

Спочатку користувач SHER, в більшості випадків, створюється адміністратором БД, автоматично надаючи емупривілегію CONNECT. В цьому випадку звичайно додається пропозиція IDENTIFIED BY. вказуюче пароль. Наприклад, для первинної реєстрації користувача адміністратор бази даних вводить наступне:

GRANT CONNECT TO SHER IDENTIFIED BY Roman

Це приведе до створення користувача з ім'ям SHER, дасть йому право реєструватися і призначить йому пароль Roman 18. Після цього SHER і адміністратор БД мають можливість при необхідності змінити пароль.

Якщо новий користувач буде створювати базові таблиці, для нього потрібно буде також надати привілей RESOURCE. Дана дія породжує іншу проблему - якщо буде зроблена спроба видалити привілей CONNECT цього користувача, і в БД є таблиці, які їм створені, команда відхилюватиме, тому що ця дія залишить таблицю без власника, що не припускає. Отже, перед видаленням користувача спочатку необхідно видалити всі створені їм таблиці.

Таким чином, привілеї дають можливість SQL виконувати дії тільки через певних користувачів в спеціальній системі БД відповідно до встановлених для них дозволів і обмежень.

ЛЕКЦІЯ№

⇐ Предыдущая 1 2 3 4 5 678 Следующая ⇒