внимание на работу [16.9], в которой описывается система с вложенными пользовательскими группами. Вот цитата из этой работы: Способность классифицировать пользователей в виде иерархии групп представляет собой мощный инструмент администрирования больших систем с тысячами пользователей и объектов .

16.2. Избирательная cxeivia управления доступо]и

Повторяя сказанное выше, следует еще раз отметить, что во многих СУБД поддерживается либо избирательная, либо мандатная схема управления доступом, либо оба эти типа одновременно. Однако точнее все же будет сказать, что в действигельности в большинстве СУБД поддерживается только избирательная схема доступа и лишь в некоторых- только мандатная. Поскольку на практике избирательная схема доступа встречается гораздо чаще, основное внимание в этой главе уделяется именно ей.

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

AUTHORITY SA3

GRANT RETRIEVE { S#, SNAME, CITY ), DELETE ON S

TO Jim, Fred, Mary ;

/* Разрешить выборку атрибутов ( St, SNAME, CITY ) и удаление */ /* данных из таблицы поставщиков пользователям Джим, Фред и Мэри */

Этот пример иллюстрирует тот факт, что в общем случае полномочия доступа включают четыре компонента.

1. Имя (в данном примере- SA3). Устанавливаемые полномочия будут зарегистрированы в системном каталоге под этим именем.

2. Одна или более привилегий, задаваемых в предложении GRANT (в нашем примере это привилегия RETRIEVE (только для некоторых атрибутов) и привилегия DELETE).

3. Задаваемое в предложении ON имя переменной-отношения, к которой применяются полномочия (в нашем примере это переменная-отношение S).

4. Один или более имен пользователей (точнее, идентификаторов пользователей), которым предоставляются указанные привилегии по отношению к переменной-отношению, задаваемой с помощью фразы ТО.

В исходном варианте языка Tutorial D [3.3] не предусмотрено никаких средств определения полномочий, однако используемый в данном разделе гипотетический язык можно рассматривать как выдержанный в духе языка Tutorial D.

Ниже приводится общий синтаксис оператора определения полномочий.

AUTHORITY <имя полномочием GRANT <список привилегий> ON <имя переменной-отношениЯ> ТО <список идентификаторов пользователей> ;

Пояснения. В приведенном выше определении смысл параметров <имя полномо-чий>, <список привилегий>, <имя переменной-отношения> и <список идентификаторов пользователей> понятен из их названий. Добавим только, что значение ALL в данном контексте может применяться для обозначения сразу всех известных пользователей. В качестве элементов списка в параметре <список привилегий> разрешается применять следующие значения.

RETRIEVE [ (<список имен атрибутов>) ] INSERT [ (<список имен атрибутов>) ] UPDATE [ (<список имен атрибутов>) ] DELETE ALL

Смысл привилегий RETRIEVE (выборка), INSERT (вставка), UPDATE (обновление) и DELETE (удаление) очевиден без дополнительных разъяснений. Если при указании привилегии RETRIEVE определен список атрибутов, то она применяется только к заданным атрибутам. Списки имен атрибутов в определениях привилегий INSERT и UPDATE имеют тот же смысл. Спецификация ALL является сокращенной записью предоставления всех привилегий - RETRIEVE (по всем атрибутам), INSERT (по всем атрибутам), UPDATE (по всем атрибутам) и DELETE.

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

Что произойдет, если пользователь попытается выполнить с объектом операцию, не имея на это необходимых полномочий? В простейшем случае достаточно просто отвергнуть эту попытку (конечно, предоставив пользователю соответствующее диагностическое сообщение). На практике такой вариант применяется наиболее часто, поэтому его можно понимать как используемый по умолчанию. Однако в более сложных ситуациях может оказаться полезным применить некоторое другое действие, например завершить выполнение программы или заблокировать клавиатуру пользователя. Также может иметь смысл фиксация всех подобных попыток в специальном журнале регистрации (т.е. проведение отслеживания угроз). Впоследствии эти данные могут оказаться полезным для выявления попыток обнаружения брешей

Хотя и не вполне, поскольку наличие привилегии RETRIEVE необходимо также в случае ссылки на некоторый объект (например, в определении представления или ограничения целостности), а не только для выполнения операции выборки.

в системе защиты, а также следов возможного нелегального проникновения в систему (подробнее вопросы контрольного слежения за процессами в системе обсуждаются в конце этого раздела).

Безусловно, необходимо также предусмотреть способ отмены существующих полномочий.

DROP AUTHORITY <имя полномочий> ;

В частности, для нашего примера он может выглядеть следующим образом. DROP AUTHORITY SA3 ;

Для простоты изложения предположим, что при удалении некоторой переменной-отнощения автоматически удаляются и все полномочия, предоставленные по отношению к ней.

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

1. AUTHORITY ЕХ1

GRANT RETRIEVE { Р#, PNAME, WEIGHT ) ON P

TO Jacques, Anne, Charley ;

Пользователи Jacques, Anne и Charley получают право доступа к указанному вертикальному подмножеству данных в базовой переменной-отношении Р. Таким образом, это пример предоставления полномочий, не зависящих от значения данных.

2. AUTHORITY ЕХ2

GRANT RETRIEVE, UPDATE (SNAME, STATUS), DELETE ON LS

TO Dan, Misha ;

Упоминаемая здесь переменная-отношение LS является представлением (представлением поставщиков из Лондона ; см. рис. 9.4 в главе 9). Пользователи Dan и Misha получают доступ к горизонтальному подмножеству данных в базовой переменной-отношении S. Это пример предоставления полномочий, зависящих от значений данных. Обратите внимание, что хотя пользователи Dan и Misha могут удалить (DELETE) некоторые кортежи поставщиков (через представление LS), они не могут вставить (INSERT) их, а также не имеют права обновлять (UPDATE) атрибуты Si и CITY.

3. VAR SSPPR VIEW

(S JOIN SP JOIN (P WHERE CITY = Rome) { Pl } )

{ ALL BUT P#, QTY } ;

AUTHORITY EX3 GRANT RETRIEVE ON SSPPR TO Giovanni ;

Это еще один пример полномочий, зависящих от значения данных: пользователь Giovanni получает доступ к информации о поставщиках, но только о тех, которые поставляют детали, хранящиеся в Риме.