Материал: Graber_Martin_-_SQL_dlya_prostykh_smertnykh_-_2014

Лишение привилегий

а затем передать права по работе с этими таблицами тем, кто реально будет с ними работать. SQL позволяет это сделать с помощью предложения WITH GRANT

OPTION.

Если Diane желает, чтобы Adrian имел право передавать полномочия на работу с таблицей Customers другим пользователям, то он должен передать Adrian привиле­ гию на выполнение команды SELECT и применить предложение WIТH GRANТ

OPTION:

GRANT SELECT ON Customers ТО Adrian

WIТH GRANT ОРПОN;

После выполнения этой команды Adrian получает право передать привилегию вы­ полнения команды SELECT третьим лицам. Для этого он должен выполнить команду:

GRANT SELECT ON Diane.Customers ТО Stephen;

или даже:

GRANT SELECT ON Diane.Customers ТО Stephen

WITH GRANT OPTION;

Пользователь с GRANT ОРПОN для отдельной привилегии для данной таблицы мо­ жет, в свою очередь, передать эту конкретную привилегию на эту таблицу с предложени­ ем или без предложения GRANТ OPТION любому другому пользователю, что не изменяет владельца таблицы: таблицы всегда принадлежат их создателям. (В качестве префикса перед именем таблицы следует указывать идентификатор создателя таблицы, как это бьто продемонстрировано в примере. В следующей главе будет показан другой способ.) Пользователь с GRANT ОРПОN на все привилегии для данной таблицы имеет большую власть над этой таблицей.

Лишение привилегий

Как ANSI определяет команду CREATE TABLE для создания таблиц, но не преду­ сматривает команды DROP TABLE для отказа от них, так же стандарт поддерживает команду GRANТ для передачи привилегии пользователям, но не предусматривает способа лишить пользователя привилегий. Потребность лишения привилегий удовле­ творяется с помощью команды REVOКE, которая де-факто стала одной из характери­

стик стандарта.

Синтаксис команды REVOKE повторяет синтаксис команды GRANТ, но имеет противоположное значение. Таким образом, лишить Adrian привилегии выполнять ко­ манду INSERT для таблицы Orders можно с помощью команды:

REVOKE INSERT ON Orders FROM Adrian;

Списки привилегий и пользователей доступны, как и для команды GRANT, значит

можно ввести следующую команду:

241

Глава 22. Определение прав доступа к данным

REVOKE INSERT, DELETE ON Customers FROM Adrian, Stephen;

Но кто имеет право лишать пользователей привилегий? Когда пользователь, имев­ ший привилегии, лишается их, лишаются ли привилегий пользователи, получившие привилегии от него? Поскольку эта характеристика не является стандартной, одно­ значных ответов не существует. Наиболее распространенным подходом является сле­ дующий: привилегии отменяются пользователем, передавшим их, и отмена привилегий осуществляется каскадно, т.е. операция применяется последовательно ко

всем пользователям, получившим привилегии от того пользователя, который их лиша­ ется в данный момент.

Использование представлений для фильтрации привилегий

С привилегиями можно работать проще, используя представления. При передаче привилегии для базовой таблицы пользователю, она автоматически применяется ко всем строкам и, с возможными исключениями для UPDATE и REFERENCES, ко всем столбцам таблицы. Создавая представление, которое ссылается на базовую таблицу, и передавая привилегии представлению, а не базовой таблице, можно ограничить их любым выражением, применимым в запросе, который формирует пре,цставление. Это во многом определяет основные возможности команды GRANT.

Кто может создавать представления? Для того, чтобы создать представление, нужно иметь привилегию использования команды SELECT для всех таблиц, на кото­ рые есть ссылка в представлении. Если представление является обновляемым, любые привилегии INSERT, UPDATE и DELETE на таблицу, лежащую в основе представле­ ния, автоматически применимы также и к представлению. Если нет привилегий об­ новления таблиц, лежащих в основе представления, то их нет и для создаваемых конкретных представлений, даже если сами представления являются обновляемыми. Поскольку внешние ключи в представлениях не применяются, нет необходимости использовать привилегию REFERENCES при создании представлений. Эти ограниче­ ния определены ANSI. Можно использовать также нестандартные привилегии (будут

рассмотрены далее в этой главе). В следующих разделах предположим, что создатели рассматриваемых представлений являются владельцами или имеют соответствующие

привилегии на все используемые базовые таблицы.

Ограничение привилегии select для определенных столбцов. Предположим, нужно дать пользователю Claire возможность видеть только столбцы snum и sname таблицы Salespeople. Это можно сделать, указав имена этих столбцов в

представлении:

CREATE VIEW Clairesview

AS SELECT snum, sname

FROM Salespeople;

и передав Claire привюеrию SELECT на представление, а не на таблицу Salespeople:

242

Лишеиие 11ривилегий

GRANT SELECT ON Clairesview to Claire;

Такие привилегии на использование столбцов можно создать, применяя и другие привилегии, но для команды INSERT это означает вставку значений по умолчанию, а для команды DELETE ограничения на столбцы будут бессмысленны. Привилегии UPDATE и REFERENCES могут быть сделаны для столбцов без изменения представ­

ления.

Ограничение области действия привилегий определенным подмножеством строк. Более полезным способом фильтрации привилегий для представлений явля­

ется использование самого представления для ограничения привилегии отдельными

строками. Естественно, для этого в представлении используется предикат, определяю­

щий какие строки интересны. Например, чтобы передать привилегию на выполнение команды UPDATE для всех покупателей (таблица Customers), расположенных в Лон­ доне (city = 'London'), Adrian, можно создать такое представление:

CREATE VIEW Londoncust

AS SELECT •

FROM Customers

WHERE city = 'London· WITH СНЕСК OPTION;

Затем можно передать привилегию UPDATE Adrian:

GRANT·UPDATE ON Londoncust ТО Adrian;

Эта привилегия отличается от определенной на столбцах привилегии UPDATE тем, что исключаются все строки таблицы Customers, в которых значение поля city от­ лично от 'London'. Предложение WIТH СНЕСК OPTION не дает возможности Adrian изменять значение поля city.

Передача прав доступа для производных данных. Можно также предоставить

пользователям доступ к производным данным, отличным от реальных данных табли­ цы. В этом случае могут быть полезны функции агрегирования. Можно создать пред­ ставление, которое дает общее число, среднюю величину и сумму по полю amt для

заказов, поступивших на каждую дату:

CREATE VIEW Datetotals

AS SELECT odate, COUNT (•), SUM (amt), AVG (amt)

FROM Orders

GROUP ВУ odate;

Теперь Dine дается привилегия выполнять команду SELECT для представления

Datetotals:

GRANT SELECT ON Datetotals ТО Oiane;

Использование представлений как альтернативы системе ограничений. Один из вариантов применения техники, упомянутой в главе 18, состоит в испо.1ьзовании представлений WIТH СНЕСК OPТION вместо ограничений. Предположим, нужно

243

Глава 22. Определение прав доступа к данны.ч

удостовериться, что все значения поля city в таблице Salespeople имеют одно и то же значение - название города, в котором в настоящее время расположен офис компа­ нии. Можно использовать ограничение СНЕСК на столбец city непосредственно, но позже будет трудно внести изменения, если компания откроет еще ряд офисов. Аль­ тернативой является создание представления, которое исключает ошибочные значе­ ния поля city:

CREATE VIEW Curcities

AS SELECT •

FROM Salespeople

WHERE city IN ("London·, 'Rome', 'San Jose·, ·вerlin')

WITH СНЕСК OPTION;

Теперь, вместо привилегии изменять таблицу Salespeople, пользователям дается при­ вилегия на предоставление им представления Curcities. Преимущество этого подхода заключается в следующем: при необходимости внести изменение можно исключить это

представление, создать новое представление и передать пользователям привилегии на

него, что гораздо проще, чем менять ограничение. Недостаток заключается в том, что владелец таблицы Salespeople также должен использовать это представление, если он хочет наверняка исключить собственные ошибки.

С другой стороны, такой метод позволяет владельцу таблицы и вс~:м другим поль­ зователям, имеющим право обновлять привилегии для самой таб.1ицы, а не для пред­ ставления, делать исключения для ограничений. Это весьма желательно, но невыполнимо при использовании ограничений на саму базовую таблицу. Эти исклю­ чения невидимы в представлении. Если применяется такой метод, можно создать вто­

рое представление, содержащее только ограничения:

CREATE VIEW Othercities

AS SELECT •

FROM Salespeople

WHERE city NOT IN ('London·, 'Rome', 'San Jose', 'Berlin')

WITH СНЕСК OPTION;

При передаче пользователям только привилегии на выполнение команды SELECT

для этого представления они смогут видеть исключенные строки, но не смогут зане­

сти ошибочные значения в базовую таблицу. Фактически пользователи могут сформу­ лировать запросы к двум представлениям, сформировать их объединение и увидеть

все строки за один раз.

Другие типы привилегий

244

Другие ти11ы 11ривилегий

Преимущественное право создавать таблицы не регламентируется ANSI. Но эту об­ ласть привилегий нельзя игнорировать (все стандартные АNSI-привилегии вытекают из нее), ведь именно создатели таблиц предоставляют привилегии на объекты. Кроме того, разрешая всем пользователям создавать базовые таблицы в системе любого размера, уве­ личивается избыточность данных и снижается эффективность системы их обработки. Следующие вопросы связаны с этим же. Кто имеет право изменять, удалять или наклады­ вать ограничения на таблицу? Огличается ли право создавать базовые таблицы от права

создавать представления? Должны ли существовать су11ер11юьзоватеш (sиperusers) -

пользователи, основной обязанностью которых является управление базой данных и ко­

торые имеют подавляющее множество или все привилегии и не имеют права их индиви­

дуальной передачи?

Поскольку ANSI не касается этих вопросов, в конкретных реализациях SQL ис­

пользуется огромное множество подходов, и невозможно дать вполне конкретные от­

веты на все эти вопросы. Можно только изложить наиболее общий подход к решению этих проблем.

Привилегии, которые не определяются в терминах отдельных объектов, называют­ ся системньини привилегия.ми (system privileges) или авторским правом на базу дан­ ных (database aиthorities). В подавляющем большинстве случаев системные привилегии включают в себя право создавать объекты данных, различать базовые таб­ лицы (обычно создаваемые силами нескольких пользователей) и представления (обычно создаваемые многими или всеми пользователями). Системная привилегия на создание представления поддерживается, в отличие от привилегии замены, объектны­ ми прищшегиями, представленными в стандарте ANSI. Кроме того, в системе любого размера существует суперпользователь. Термин, чаще всего используемый для такого суперпользователя и его привилегий, - администратор базы данных (DBA -

Database Administrator).

Типичная система привилегий

Обычно принято различать три типа базовых систем привилегий, которые называ­ ются CONNECT, RESOURCE и DBA. CONNECT предусматривает право входить в систему и создавать представления и синонимы (см. главу 23), если речь идет об объ­ ектных привилегиях. RESOURCE предоставляет право создавать базовые таблицы. DBA - это привилегия суперпользователя, дающая право пользователю распоря­ жаться базой данных по своему усмотрению (как своей собственной). Эту привиле­ гию имеет пользователь (один или несколько) с функцией администрирования базы данных. В некоторых системах есть также специальный пользователь (иногда назы­ ваемый SYSADM или просто SYS), обладающий высшим авторским правом; это спе­ циальное обозначение пользователей, в отличие от имеющих привилегию DBA. SYSADM рассматривается как идентификатор по,1ьзователя. Различия в названиях и приписанных им действиях существенны для различных систем. Мы будем ссылаться на самого высоко привилегированного пользователя (или пользователей), который за­ нимается проектированием и управлением базой данных как на пользователя DBA, отражая тот факт, что за этим названием скрывается скорее функция чем привилегия.

245