7.4 Защита и авторизация пользователя в SQL2

в SQL2 постулируется существование идентификаторов (ID) авторизации, ко-торьЕС, по сушеству, являются именами пользонагелеп. В SQL есть специальный ID авторизащш PUBLIC, включающий в себя любого пользователя ID авторизаиии MOivT быть npiiCBoeibi привилегии. Они присваиваются 1Ю многом так же, как п в среде файловой системы, поддерживаемой операцтюнОй системой. Например, система UNI.X обЬ1чно контролирует три вида привилегий; чтения, записи и выпол-не Н1Я. Список привилегий и.меет смысл, так как защищаемыми объектами систе.мы UNIX являются файлы и эти тр-i привилегии хорошо отражают то, что обычно можно сделать с фаГыами- Но БД намного сложнее файловых систем и. соответсг-венно, п S0L2 используются более сложные привилегии.

В этом разделе сначала будут рассмотрены привилегии, допустимые на элемен-гах БД по стандарту S0L2, а затем мы покажем, как их может получить поаьзова-гель (т.е. ID авторизашш) и как он может их лишиться.

7-4-1 Привилегии

В SQL2 определетю шестъ типов привилегий: К SELECT

2. INSERT

3. DELETE

4. UPDATE

5. REFERENCES

6. USAGE

Первые четыре гипа относятся к 0Т1Юшениям, которые могут быть таблицами базы или П1кдста(!леннями. В соответствии со своими названиями они дают обладателю пр1-Н)илегии запрашнва ь отношение (выбирать что-то из него), вводить, удалять пли изменять кортежи отношения. Модуль, содержащий SQL-предложение, невозможно выполнить без привилегии, связанной с этим модулем; например, аредчоженне типа select-from-wliere требует привилегии SELECT для каждой исполь-зуе1Юй я нем таблицы Рассмотрим, как модуль может получить перечисленные привилегии.

Привилегия REFERENCES - это право ссылаться на отношение в о раничении целостности. Такие ограничения могут иметь любую форму из описанных в главе 6. Ограничение нель.1Я проверить, есл i схема, содержащая это ограничение, не имеет приинлепш REFERENCES на все данные. сод1.ржашисся в ограничении.

Привилегия на область и и на другие виды элементов схемы, отличные от отношений и допущений (см. раздел 7 3.2),- это право использовать эт1 элементы в своих собственных описан1ях.

Три лрипнг](.Г11и - INSERT, UPDATE и REFERENCES - могут бы ь присвоены одинстненному атрибуту, выступающему в качестве .1ргуменга. В этом случае при-11иле1ия ОТН0СН1СЯ олько к указанному атрибут/ Можно примещтгь множество привилегий. к.!жлая из которых относится к единственно.му атрибуту, и таки.м образом авторпзоаать доступ к любому подмножеству столбцов отношения

Пример 7.20. Рассмотрим, какие привилегии нужны дпя выполнен! я вставки иорте..кей из рис. 5.12 воспроизведенного на рис. 7.14 Здесь выполняется кставка кортежей II опюшение Studio, поэтому н\жн1 прнвтегня INSERT на это отношеше. Но поскольку bctilBk.! касается еяинственного компонента атрибута name, аосгэточ МО иметь н<1 это отношение привилегию INSERT или привилегию INSERT(name).

Последняя позволяет вставлять кортежи отношения Studio, которые определяют только компйиент name и оставляют другие компоненты с их значениями по умолчанию или NULL, что и показано на рнс. 7.14.

1) INSERT INTO Studio(name)

2) SELECT DISTINCT studioName

3) FROM Movie

4) WHERE StudioName NOT IN

5) (SELECT name

6) FROM Studio}:

pHt. 7.14. Добовление новых студий

Однако оператор вставки на рис. 7.14 содержит два подзапроса, начинающиеся на строках (2) и (5). Для их шлполнения нужны привилегии для подзапросов. Таких! образом, необходима привилегия SELECT на оба отношения - Movie и Studio, включенные в пункты FROM. За.метим, что иметь привилегию INSERT на отношение Studio совсем не значит иметь привилегию SELECT ип это же отношение и. наоборот, иметь иторую из них не значит иметь и первую. Q

7.4.2 Создание привилегий

Рассмотрим теперь, как получить привилегии для выполнения 80Е-предложен11й. Есть два момента присвоения привилегий: их первоначгыьное создание и передача от пользователя пользователю. Создание привилетй рассматривается в этом разаеле, а их передача в разделе 7.4.4.

Прежде всего элементы SQL. такие как схемы шш модули, принвд7ежат владельцу, который имеет связанные с ними привилеши. В SQL владение устанавливается в трех случаях:

1. При создании схемы Предполагается, что она. все ее таблицы и прочие элементы принадлежат соз-аавшему их пользователю, который имеет все возможные привилегии на элементы этой схемы.

2. При запуске сеанса с помощью оператора CONNECT есть возможность указать пользователя, применив ключевое слово USER. Например, оператор связи

CONNECT ТО Starfleel-sql-server AS conni USER kirk:

создает для пользователя kirk связь conni с сервером Starfleet-sql-server. Предполагается, что реализация SQL верифицирует имя пользователя, например, запрашивая пароль,

3. При создании модуля ему можно присвоеть владельца, используя ключевое слово AUTHORIZATION. Подробности создания модулей здесь не рассмат-рипаютси. так как craii/iapr SQL2 обеспечивает в этом плане широкие возможности лля различных реализаций. И все же можно считать, что пункг

AUTHORIZATION picard;

в операторе создания модуля делает picard владельцем этого моку) я. Если е;адельца модуля не указьиить. то этот модуль может выполняться любым пользовдтелем; но в таком случае привилеши, необходимые для выполнения любо11 операции в мшуле, должны постпать из какого-то другого источника, например от пользователя, относящегося к данной связи и сеансу, в течение которого выполняется модуль.

7.4-3 Процесс контро.чя привилегий

Каждая схема, каждый модуль и сеанс имеют спнзаниого с ними пользователя; в терминологии SQL это означает, что дпя них существуют ID авторизашн1. Любая операция SQL имеет две стороны.

L Элементы БД, ни которых выполняется операция.

2. А\гент. выполняющщ ! операцию.

Привилегии агента выводятся нз конкретного ID авторизации, который 1йзываегся текущим ID авторизации и является:

a) ID авторизации модуля, еспи модуль, выполняемый агентом, имеет ID;

b) ID авторизации сеанса, еслн у модуля нет 10.

Операцию SQL можно выполнить, только если текущщ! Ю авторизации имеет все привилегии, необходимые для выполнения этой операции.

Пример 7.21. Чтобы понять механизм проверки привилегий, рассмотрим пример 7.20. Можно предположить, что отношения Movie и Studio - части схемы MovieSchema, созданной пользователем janeway и принадлежащего ему. Тогда поль-з ватель janeway имеет все привилегии на эти таблицы и на псе остальные элементы схемы MovieSchema. Некоторые привилегии он может передать другим при помощи механизма, показанного в разделе 7.4.4, но сейчас мы предполагаем, что ни одна привилегия еще не передана. Операция вставки из примера 7.20 выполняется различными способами.

1. Введение можно выполнить как часть модуля, созданного пользователем janeway и содержащего оператор AUTHORIZATION janeway. ID авторизации модуля, если он существует, всегда становится текущим ID авторизации. Значит, этот модуль и SQL-предложения вставки имеют такие же привилегии, как и janeway, т.е. все привилегии на отношения Movie и Studo.

2. Вставка может быть частью модуля, не имеющего владельца. Пользователь janeway открывает связь, вводя USER janeway в оператор CONNECT ТО. Теперь janeway - это текущий ID авторизации и предложение вставки имеет все необходимые привилегии.

3. Пользователь janeway передает все привилегии на отношения Movie и Studio пользователю sisko или пользователю PUBLIC, обозначающему всех пользователей . Предложение вставки находится в модуле с оператором

AUTHORIZATION sisko;

Поскольку текущим ID авторизации теперь является sisko и он имеет необходимые привилегии, введение разрешено.

4. Как и в предыдущем случае (пункт 3), пользователь janeway передает пользователю sisko необходимые привилегии. Предложение вставки находится в модуле без владельца и выполняется в сеансе, ID авторизации которого установлен оператором USER sisko. Значит, текущим ID авторизации является sisko и этот ID имеет все необходимые привилегии. □

Пример 7.21 иллюстрирует несколько принципов.

Необходимые привилегии всегда доступны, если данными владеет пользователь, чей ID является текущим ID авторизации. Это иллюстрируют описанные выше ситуации (1) и (2).