Призначення та видалення прав. Завдання прав. команда grant Використання уявлень для фільтрації привілеїв

GRANT priv_type [(column_list)] [, priv_type [(column_list)] ...] ON (tbl_name | * | *.* | db_name.*) TO user_name "password"] [, user_name ...] ] ] ] REVOKE priv_type [(column_list)] [, priv_type [(column_list)] ...] ON (tbl_name | * | *.* | db_name.*) FROM user_name [, user_name ...]

GRANT включений у MySQL, починаючи з версії 3.22.11 і вище. У попередніх версіях MySQL оператор GRANT нічого не виконує.

Команди GRANT та REVOKE дозволяють системним адміністраторам створювати користувачів MySQL, а також надавати права користувачам або позбавляти їх прав на чотирьох рівнях привілеїв:

Глобальний рівеньГлобальні привілеї застосовуються до всіх баз даних на вказаному сервері. Ці привілеї зберігаються у таблиці mysql.user. Рівень бази данихПривілеї бази даних застосовуються до всіх таблиць зазначеної бази даних. Ці привілеї зберігаються в таблицях mysql.db та mysql.host. Рівень таблиціПривілеї таблиці застосовуються всім стовпцям зазначеної таблиці. Ці привілеї зберігаються у таблиці mysql.tables_priv. Рівень стовпцяПривілеї шпальти застосовуються до окремих стовпців зазначеної таблиці. Ці привілеї зберігаються у таблиці mysql.columns_priv.

Якщо привілеї надаються користувачеві, якого немає, цей користувач створюється. Щоб переглянути приклади роботи команди GRANT, див. розділ 4.3.5 Додавання нових користувачів до MySQL.

У таблиці наведено список можливих значень параметра priv_type для операторів GRANT та REVOKE:

ALL	Задає всі прості привілеї, крім WITH GRANT OPTION
ALTER	Дозволяє використання ALTER TABLE
CREATE	Дозволяє використання CREATE TABLE
CREATE TEMPORARY TABLES	Дозволяє використання CREATE TEMPORARY TABLE
DELETE	Дозволяє використання DELETE
DROP	Дозволяє використання DROP TABLE.
EXECUTE	Дозволяє користувачеві запускати збережені процедури (для MySQL 5.0)
FILE	Дозволяє використання SELECT ... INTO OUTFILE та LOAD DATA INFILE.
INDEX	Дозволяє використання CREATE INDEX and DROP INDEX
INSERT	Дозволяє використання INSERT
LOCK TABLES	Дозволяє використання LOCK TABLES на таблицях, для яких є привілей SELECT.
PROCESS	Дозволяє використання SHOW FULL PROCESSLIST
REFERENCES	Зарезервовано для використання у майбутньому
RELOAD	Дозволяє використання FLUSH
REPLICATION CLIENT	Надає користувачеві право запитувати місцезнаходження головного та підлеглих серверів.
REPLICATION SLAVE	Необхідно для підлеглих серверів під час реплікації (для читання інформації з бінарних журналів головного сервера).
SELECT	Дозволяє використання SELECT
SHOW DATABASES	SHOW DATABASES виводить усі бази даних.
SHUTDOWN	Дозволяє використання mysqladmin shutdown
SUPER	Дозволяє встановити одне з'єднання (один раз), навіть якщо досягнуто значення max_connections, і запускати команди CHANGE MASTER , KILL thread , mysqladmin debug , PURGE MASTER LOGS та SET GLOBAL
UPDATE	Дозволяє використання UPDATE
USAGE	Синонім для "без привілеїв"".

Значення USAGE можна задавати, якщо потрібно створити користувача без привілеїв.

Привілеї CREATE TEMPORARY TABLES, EXECUTE, LOCK TABLES, REPLICATION…, SHOW DATABASES та SUPER є новими для версії 4.0.2. Щоб скористатися цими новими привілеями після оновлення до версії 4.0.2 необхідно запустити скрипт mysql_fix_privilege_tables .

У більш старих версіях MySQL привілей PROCESS надає такі ж права, як і новий привілей SUPER.

Щоб позбавити користувача привілеїв, наданих командою GRANT, скористайтеся значенням priv_type у GRANT OPTION:

Mysql> REVOKE GRANT OPTION ON ... FROM ...;

Для таблиці можна вказати лише наступні значення priv_type: SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, GRANT, I NDEX та ALTER.

Для стовпця можна вказати лише наступні значення priv_type (при використанні оператора column_list): SELECT , INSERT та UPDATE .

Глобальні привілеї можна встановити, скориставшись синтаксисом ON *.* , а привілеї бази даних - за допомогою синтаксису ON db_name.* . Якщо вказати ON * при відкритій поточній базі даних, привілеї будуть задані для цієї бази даних. ( Попередження: якщо вказати ON * при відсутностівідкритої поточної бази даних, це вплине на глобальні привілеї!)

Для того, щоб можна було визначати права користувачам з конкретних комп'ютерів, MySQL забезпечує можливість вказувати ім'я користувача (user_name) у формі . Якщо потрібно вказати рядок user , у якому містяться спеціальні символи (такі як `-") або рядок host , у якому містяться спеціальні або групові символи (такі як `%"), можна укласти ім'я віддаленого комп'ютераабо користувача в лапки (наприклад, "test-user"@"test-hostname").

Також можна вказати групові символи в імені віддаленого комп'ютера. Наприклад, "%.loc.gov" відноситься до користувача всіх віддалених комп'ютерів домену loc.gov , а "144.155.166.%" відноситься до користувача всіх віддалених комп'ютерів підмережі 144.155.166 клас C.

Проста форма user є синонімом для "%".

MySQL не підтримує групові символи в іменах користувачів. Анонімні користувачі визначаються вставкою записів User="" у таблицю mysql.user або створенням користувача з порожнім ім'ям за допомогою команди GRANT.

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

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

Mysql> SELECT Host,User FROM mysql.user WHERE User="";

На даний момент команда GRANT підтримує імена віддалених комп'ютерів, таблиць, баз даних та стовпців завдовжки не більше 60 символів. Ім'я користувача має містити не більше 16 символів.

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

Привілеї для стовпця можуть бути обчислені таким чином:

Глобальні привілеї OR (привілеї бази даних AND привілеї віддаленого комп'ютера) OR привілеї таблиці OR привілеї стовпця

Найчастіше права користувача визначаються лише одному рівні привілеїв, тому зазвичай ця процедура не настільки складна, як описано вище. Детальна інформаціяПро послідовність дій перевірки привілеїв представлено в розділі 4.2 Загальні проблеми безпеки та система привілеїв доступу MySQL.

Якщо привілеї надаються поєднанню користувач/віддалений комп'ютер, яке відсутнє в таблиці mysql.user , то до останньої додається запис, яка залишається в таблиці доти, доки не буде видалена за допомогою команди DELETE . Інакше висловлюючись, команда GRANT може створювати записи user у таблиці, але команда REVOKE неспроможна їх видалити. Це необхідно робити за допомогою команди DELETE.

Якщо у вас є привілеї для бази даних, то при необхідності в таблиці mysql.db створюється запис. Цей запис видаляється після видалення всіх привілеїв для цієї бази даних командою REVOKE.

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

Оператор WITH GRANT OPTION надає користувачеві можливість наділяти інших користувачів будь-якими привілеями, які він має на вказаному рівні привілеїв. При наданні привілею GRANT необхідно виявляти обачність, оскільки два користувача з різними привілеями можуть об'єднати свої привілеї!

Параметри MAX_QUERIES_PER_HOUR # , MAX_UPDATES_PER_HOUR # та MAX_CONNECTIONS_PER_HOUR # є новими у MySQL версії 4.0.2. Ці параметри обмежують кількість запитів, оновлень та входів, які користувач може здійснити протягом однієї години. Якщо встановлено значення 0 (прийнято за замовчуванням), це означає, що для цього користувача немає обмежень. See section.

Не можна надати іншому користувачеві привілей, якого немає у вас самого. Привілей GRANT дозволяє надавати тільки ті привілеї, які ви маєте.

Врахуйте, що якщо користувачу призначено привілей GRANT на певному рівні привілеїв, то всі привілеї, якими цей користувач вже володіє (або які будуть призначені йому в майбутньому!) на цьому рівні, також можуть призначатися цим користувачем. Припустимо, користувачеві призначено привілей INSERT у базі даних. Якщо потім у базі даних призначити привілей SELECT і вказати WITH GRANT OPTION, користувач зможе призначати не тільки привілей SELECT, але й INSERT. Якщо потім у базі даних надати користувачеві привілей UPDATE, користувач зможе після цього призначати INSERT, SELECT та UPDATE.

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

Зверніть увагу на те, що якщо використовуються привілеї для таблиці або стовпця навіть для одного користувача, сервер перевіряє привілеї таблиць і стовпців для всіх користувачів, і це дещо уповільнює роботу MySQL.

При запуску mysqld всі привілеї зчитуються на згадку. Привілеї бази даних, таблиці та стовпця набувають чинності негайно, а привілеї рівня користувача - при наступному підключенні користувача. Зміни у таблицях призначення привілеїв, які здійснюються за допомогою команд GRANT та REVOKE, обробляються сервером негайно. Якщо змінювати таблиці призначення привілеїв вручну (використовуючи команди INSERT , UPDATE тощо), необхідно запустити оператор FLUSH PRIVILEGES або mysqladmin flush-privilege s, щоб вказати серверу необхідність перезавантаження таблиць призначення привілеїв. See section 4.3.3 Коли зміни в привілеях набувають чинності.

Найбільші відмінності команди GRANT версій ANSI SQL і MySQL наступні:

• MySQL привілеї призначаються для поєднання ім'я користувача + віддалений комп'ютер, а не тільки для імені користувача.
• У ANSI SQL відсутні глобальні привілеї та привілеї рівня бази даних, і ANSI SQL підтримує не всі типи привілеїв MySQL. У свою чергу, MySQL відсутня підтримка привілеїв ANSI SQL TRIGGER , EXECUTE або UNDER .
• Структура привілеїв ANSI SQL є ієрархічною. Якщо видалити користувача, всі призначені цьому користувачеві привілеї будуть скасовані. У MySQL призначені привілеї не скасовуються автоматично, їх за потреби потрібно видаляти самостійно.
• У MySQL користувач може застосовувати до таблиці оператор INSERT за наявності у нього привілею INSERT лише кількох стовпців у цій таблиці. Стовпці, для яких відсутній привілей INSERT , будуть встановлені у значення, прийняті за умовчанням. У ANSI SQL потрібна наявність привілею INSERT всім стовпців.
• При видаленні таблиці в ANSI SQL всі привілеї цієї таблиці будуть скасовані. Якщо скасувати привілей у ANSI SQL, то всі привілеї, які були призначені на основі цього привілею, також будуть скасовані. MySQL привілеї можуть видалятися тільки за допомогою команди REVOKE або шляхом зміни таблиць призначення привілеїв MySQL.

Щоб переглянути опис використання REQUIRE, див. розділ See section 4.3.9 Використання безпечних з'єднань.

User Comments

Posted by Frank Wortner

[Delete] [Edit]

I had no problems with ld. DEC (Compaq) might
має fixed ld in a patch kit. You might want to
install the latest patch kit for your Digital Unix
(Tru64 Unix) before building MySQL. Patch kits
є available at
href=http://ftp.support.compaq.com/public/unix/ >
http://ftp.support.compaq.com/public/unix/

Posted by on Saturday February 16 2002, @10:21pm

[Delete] [Edit]

Для інформаційних ресурсів, ці інструкції відносяться до осередку структури керування "usr/local" був використаний (розширений) з configure. Але , щоб переглянути page's інструкції (для compilation/installation) suggest you use:

./configure --prefix=/usr/local/mysql

Для того, щоб бути (і це спричиняє мою мету з Perl, але це не вірно semantic), інструкції на цій сторінці слід запустити /usr/local/mysql була спрямована на налаштування directory з configure.

Posted by Linda Wright on Saturday February 16 2002, @10:21pm

[Delete] [Edit]

This is probably the most important and least
appreciated sections of all of the mySQL
documentation for first time mySQL users. IMHO,
reading this page in conjunction with
http://www.mysql.com/doc/P/r/Privileges.html is a
must for anyone planning secure database системи
of any real sophistication.

Posted by Christopher Raymond on Saturday February 16 2002, @10:21pm

[Delete] [Edit]

I m trying to install MySQL під OS X Public Beta. When I run the script, mysql_install_db, I get an error message:

Dyld: ./bin/mysqld can"t open library: /usr/lib/libpthread.A.dylib (No such file або directory, errno = 2)
Installation of grant tables failed!

I am assuming that the script is looking for a directory that doesn"t exist because Apple has little bit different directory naming structure. Maybe this script needs to be modified for the OS X distribution.

Can anyone help?

Posted by Mark Zieg on Saturday February 16 2002, @10:21pm

[Delete] [Edit]

Це буде добре, якщо це було з'єднання з log connections, але не потребує.

Posted by Bennett Haselton on Saturday February 16 2002, @10:21pm

[Delete] [Edit]

Якщо ви "logged on as mysql root user, без поточного database selected, and you try to
grant all privileges to a user with the command:

GRANT ALL PRIVILEGES ON * TO bhaselto

The RELOAD, SHUTDOWN, PROCESS, FILE і GRANT не буде granted, as can be
Verified за допомогою "user" table of "mysql" database. (This is presumably by design,
since ці привілеї може зробити "user fulful".)

Posted by DC Hill on Saturday February 16 2002, @10:21pm

[Delete] [Edit]

NOTE: Якщо ви маєте прямі привілеї, щоб скористатися ним на окремому 데이터베이스, або на будь-який рівень, що не вказує на "REVOKE ALL ON *.* FROM ;" will NOT revoke privileges at those levels. *.* в обох статевих засобах "global", не "all (individual) tables on all (individual) database. Привілеї в тій самій людині вони були захищені, якщо ви збираєтеся перейти з привілеїв tables.(i.e. - GRANT ALL ON foo. You a little time and frustration.

Posted by Cris Perdue on Saturday February 16 2002, @10:21pm

[Delete] [Edit]

"Як ви маєте процеси привілею, ви можете повідомити
all threads.
Іншіwise, ви можете бачити тільки ваші власні threads."

Posted by FreeBSD Forums on Saturday February 16 2002, @10:21pm

[Delete] [Edit]

Ви можете використати phpMyAdmin web based tool to do a lot
of mySQL admin functions. href="http://www.freebsdforums.org"
>FreeBSD forums

Posted by on Monday February 25 2002, @6:03am

[Delete] [Edit]

Verified on MySQL 3.23.36 on Red Hat Linux 7.1:
Note that if you type
use a_c;
grant select on * to;
You will have given access to any
database matching "a_c" where the underscore is a
Wildcard. (Rarely a problem, I suppose).
Rectify with
update mysql.db set db="a\_c" where db="a_c";

Posted by jan behrens on Tuesday July 9 2002, @1:31am

[Delete] [Edit]

aformentioned bug from DAN ELIN in x.x.41 is
apperently still valid in x.x.51,i cannot logon to a
database after GRANTing privileges and given a
password to a new user(yes, i flushed
privileges)...................only root access is possible

Posted by Dan Egli на Thursday April 4 2002, @8:33pm

[Delete] [Edit]

Вони можуть бути в 3.23.41 шляхом Grant.
Only root can access the mysql database, even
після використання Grant to grant privs on whatever
database/table/column/ect.. you always get
Permission denied, regardless.

Posted by Lars Aronsson on Saturday June 8 2002, @11:16am

["%". When I try to delete them I'm told certian database, but no global privileges, the CREATE TEMPORARY TABLE privilege on that database is denied. You have to give Global CREATE __and__ Global CREATE TEMPORARY TABLES to the user. IOW: GRANT CREATE, CREATE TEMPORARY TABLES ON *.* TO ; Потрібно не думати, що ці проблеми сприятливі. Posted by on Sunday August 25 2002, @9:17am [Delete] [Edit] Temporary files are a great idea but even with Create and Create Temproary File rights in the user (global rights) file it still doesn"t work. Це з'явиться, щоб бути погано designed. Posted by Brad Bulger on Monday September 2 2002, @4:09am [Delete] [Edit] It should be noted that WITH GRANT OPTION тільки allows the user to pass on privileges to users who already exist. Automagical creation of user records does not apply - you get an error saying that the user with the GRANT OPTION privilege does немає доступу до "mysql" database. This is probably a good thing, але це потребує be documented. Posted by Michael Babcock on Friday November 8 2002, @1:00pm [Delete] [Edit] SHOW MASTER STATUS requires PROCESS privileges. Інші такі комбінації, як правило, повинні бути документовані. Posted by Dee Kintaudi на Thursday November 21 2002, @12:42pm [Delete] [Edit] Okay I got a question and problem with Mysql and passwords:). I tried to use several of the options and most them have not worked. However one solution did work and I tested it out twice and it was solid. Of course I втратив короткий кінець паперу I wrote it out on and I can't seem to find this solution anywhere, as if it did not exist or maybe I imagined it. The solution that worked for me, before I lost the little slip of paper I wrote it down on goes something like this..... Insert into user root Password "my password" and then something з "Y", "Y", "Y", (about a dozen або 15 times or so) However, Я не може виконати це рішення будь-де може someone help me out here? I think it would be so nice if they just put this за допомогою своєї документації досліджує здійснити hide it. I think this would solve many problems. Just put password = "Y", "Y", "Y", його як їх shamed of it або деякий. Posted by AJIT DIXIT on Monday November 25 2002, @6:56am [Delete] [Edit] When I work on multi-table update with root user it works fine When I work with non-root user I get error Sql: update Stockists, areas set a_nm = aname where acd = area

У цьому розділі ви навчитеся роботі з привілеями. Як сказано в Розділі 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 робити запити у таблиці Замовників, але забороніть йому зменшувати оцінки у тій же таблиці Замовників.

Платформа 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.

Користувачі можуть отримати дозвіл надавати права іншим користувачам передачею прав за списком , який задається опцією WITH GRANT OPTION. Користувач може видавати іншим лише ті права, які має сам.

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

Перелік прав наведено у табл. 8.5.

Таблиця 8.5. Перелік прав

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

Синтаксис:

GRANT (all / PRIVILEGES] / LJST_ ) ON (TABLE ]

(tablename/viewname)

TO (