где <привилегии>, <объект>, <список пользователей> и <список ролей> имеют такой же синтаксис, как и в запросе GRANT.

При отмене привилегий запросом REVOKE необходимо учитывать следующие ограничения и правила:

- привилегии могут быть удалены только тем пользователем, который их предоставил;

- привилегии, присвоенные другими пользователями, не затрагиваются;

- удаление конкретной привилегии для пользователя А, которому было дано право передавать ее, автоматически удаляет эту привилегию для всех пользователей, кому она была последовательно передана пользователем А;

- привилегии, переданные для общего пользования (PUBLIC), могут быть отобраны только у PUBLIC, а не у конкретного пользователя или объекта

Зарезервированное предложение GRANT OPTION FOR используется для отмены права передавать привилегии другим пользователям. Например, для отмены права пользователя Ivanov передавать привилегию на выборку данных из таблицы Abonent другим пользователям нужно использовать следующий запрос:

REVOKE GRANT OPTION FOR SELECT ON Abonent FROM Ivanov;.

После выполнения этого запроса пользователь Ivanov лишится права передавать другим пользователям привилегию SELECT на таблицу Abonent при сохранении им привилегии на доступ к таблице Abonent.

Зарезервированное предложение ADMIN OPTION FOR используется для отмены права передавать роли другим пользователям.

Особенность отмены права передавать привилегии или роли заключается в каскадности такой отмены. Проиллюстрируем это на следующем примере. Пусть на сервере был зарегистрирован пользователь Slonov и администратор SYSDBA передал ему следующие привилегии:

GRANT ALL ON PaySumma TO Slonov WITH GRANT OPTION;. Пользователь Slonov выполнил следующий запрос:

GRANT SELECT, DELETE ON PaySumma TO Ivanov WITH GRANT OPTION;. Пользователь Ivanov в свою очередь передал привилегию SELECT пользователю Petrov с помощью следующего запроса: GRANT SELECT ON PaySumma TO Petrov;. Затем администратор SYSDBA отменил право пользователя Slonov передавать привилегию SELECT другим пользователям (с сохранением права передавать DELETE привилегию) с помощью следующего запроса: REVOKE GRANT OPTION FOR SELECT ON PaySumma

FROM Slonov;.

Таким образом, в результате каскадного удаления прав:

- пользователь Slonov не имеет права передавать привилегию SELECT;

- пользователь Ivanov вообще лишен привилегии SELECT, а имеет лишь

привилегию DELETE (но с опцией WITH GRANT OPTION);

- у пользователя Petrov нет никаких привилегий на доступ к таблице PaySumma. Это произошло, потому что у пользователя Slonov отобрано право передачи привилегии SELECT другим пользователям, а значит, и все действия, которые он произвел, имея это право, также аннулированы (отобрана привилегия SELECT у пользователя Petrov, которую передал ему Ivanov).

Следует отметить, что при передаче пользователям права передавать привилегии может возникнуть проблема множественной передачи. Пусть, например, каждый из пользователей - Slonov и Ivanov, имея соответствующие привилегии, выполнили следующий запрос:

GRANT SELECT ON Request TO Petrov WITH GRANT OPTION;.

Потом IVANOV выполнил следующий запрос:

REVOKE SELECT ON Request FROM Petrov; и решил, что после этого пользователь Petrov не имеет доступа к таблице Request. Но у пользователя Petrov сохранилась привилегия, которую передал ему Slonov, и он по-прежнему имеет доступ к таблице Request.

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

Чтобы удалить привилегии, переданные какой-либо роли, можно использовать запрос REVOKE или просто удалить соответствующую роль со всеми ее привилегиями. Например, удаление роли PetrovROLE будет выглядеть следующим образом:

DROP ROLE Petrov ROLE;.

7.1.5. Привилегии на представления

Для контроля доступа к таблицам БД могут быть использованы представления. Представление обычно создается как подмножество столбцов и строк для одной или нескольких таблиц. Из-за этого представление в определенной степени обеспечивает безопасность доступа. Для обеспечения доступа представлений к базовым объектам и последующего доступа пользователей к представлению необходимо использовать запрос GRANT.

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

Пусть, например администратор SYSDBA передал привилегии пользователю Petrov с помощью следующего запроса:

GRANT ALL ON Abonent TO Petrov;.

Допустим, что Petrov создает представление Ab fio, используя следующий запрос:

CREATE VIEW Ab fio AS SELECT AccountCD, Fio FROM Abonent;.

Данный запрос будет выполнен успешно, так как Petrov имеет права на доступ к таблице Abonent. Допустим, Petrov пытается создать еще одно представление и формирует следующий запрос: CREATE VIEW Req

AS SELECT AccountCD, IncomingDate FROM Request;.

Данный запрос не будет выполнен и будет выдано сообщение об ошибке no permission for SELECT access to TABLE/VIEW REQUEST (нет разрешения на SELECT доступ к таблице Request).

Для обеспечения доступа к представлению только для чтения владелец должен предоставить пользователям привилегию SELECT на это представление.

Примечание. Для самого представления не требуется передавать привилегии на доступ к таблицам, на которых оно основано.

На обновляемые представления могут передаваться привилегии INSERT, DELETE и UPDATE. Однако существуют определенные сложности, если представление является обновляемым или если оно включает другие представления или ХП выбора. Если представление обновляемое, то модификации данных в таком представлении приводят к модификациям данных в базовых таблицах. Поэтому владельцы базовых таблиц должны предоставить пользователю соответствующие права доступа (INSERT, DELETE, UPDATE) к этим таблицам. Если представление обращается к другим представлениям или ХП выбора, то их владельцы должны предоставить пользователю привилегию SELECT на соответствующую ХП или представление. Привилегии к базовым объектам также должны быть предоставлены самому представлению.

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

Например, пусть пользователь Petrov создает представление с помощью следующего запроса:

CREATE VIEW Ab Str

AS SELECT AccountCD, StreetCD, Fio FROM Abonent;.

Затем Petrov пробует обновить строку в представлении следующим образом: UPDATE Ab Str SET StreetCD=7 WHERE AccountCD=005488;. Этот запрос не будет выполнен, пока не будут переданы привилегии с помощью следующего запроса:

GRANT REFERENCES (StreetCD) ON Street TO Ab Str;. Причем в данном случае, так как Petrov не имеет прав доступа к таблице Street, последний оператор может быть выполнен только администратором.