Хелен Борри - Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

Следующий оператор удаляет две привилегии к таблице CUSTOMER у хранимой процедуры COUNT_BEANS:

REVOKE INSERT, DELETE

ON CUSTOMER

FROM PROCEDURE COUNT_BEANS;

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

Как и в случае GRANT, отмена привилегий REVOKE ALL объединяет привилегии SELECT, INSERT, UPDATE, DELETE и REFERENCES в одном выражении. Данный оператор отменит любое из этих назначенных полномочий.

Например, следующий оператор отменит все привилегии доступа к таблице

DEPARTMENTS у пользователя MAGPIE:

REVOKE ALL ON DEPARTMENTS FROM MAGPIE;

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

REVOKE ALL не отменяет:

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

* привилегии, полученные как PUBLIC;

* привилегии EXECUTE.

Синтаксис отмены привилегии EXECUTE к хранимой процедуре:

REVOKE EXECUTE

ON PROCEDURE <���имя-процедуры>

FROM <���получатель> [, <���получатель> [, ...]]

| [TRIGGER <���имя-триггера> [, <���имя-триггера> [,...]]

[PROCEDURE <���имя-процедуры> [, <���имя-процедуры> [, ...]]

[VIEW <���имя-просмотра> [, VIEW <���имя-просмотра> [, ...]];

Следующий оператор удаляет привилегию EXECUTE у пользователя HPOTTER к процедуре COUNT_CHICKENS:

REVOKE EXECUTE ON PROCEDURE COUNT_CHICKENS FROM HPOTTER;

Теперь мы рассмотрим как получатели привилегий, указанные в предложении FROM оператора REVOKE, могут быть объединены для отмены привилегий.

Используйте разделенный запятыми список пользователей для отмены привилегий у множества пользователей в одном операторе. Следующий оператор удаляет привилегии INSERT и UPDATE к таблице DEPARTMENTS у троих пользователей за один раз:

REVOKE INSERT, UPDATE

ON DEPARTMENTS

FROM MAGPIE, BRUNHILDE, KILROY;

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

REVOKE UPDATE

ON DEPARTMENT

FROM CARTEBLANCHE;

Теперь пользователи, которым была назначена роль CARTEBLANCHE, больше не имеют привилегии UPDATE к таблице DEPARTMENT, но у них остаются другие привилегии (SELECT, INSERT, DELETE, REFERENCES, EXECUTE), которые они могли наследовать от

CARTEBLANCHE.

Вы можете использовать один оператор для отмены одних и тех же привилегий у одной или более ролей:

REVOKE DELETE, INSERT

ON DEPARTMENT

FROM CARTEBLANCHE, MAITRE_D;

Отмена назначенных роли пользователей отменяет у этих пользователей все полномочия, которые они получили с этой ролью. Используйте REVOKE для удаления роли, которую вы назначали пользователям. Следующий оператор отменяет роль

CARTEBLANCHE у пользователя KILROY:

REVOKE CARTEBLANCHE FROM KILROY;

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

Для отмены привилегий у одной или более процедур, триггеров или просмотров включите соответствующее ключевое слово (PROCEDURE, TRIGGER, VIEW) перед именем объекта.

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

Следующий оператор удаляет привилегии INSERT и UPDATE К таблице CUSTOMER для двух процедур и триггера:

REVOKE INSERT, UPDATE

ON CUSTOMER

FROM PROCEDURE COUNT_CHICKENS, ABANDON_OLD

TRIGGER AI_SALES ;

Для отмены привилегий, которые все пользователи получили как пользователь PUBLIC, просто трактуйте PUBLIC, как и любого другого пользователя. Например, следующий оператор отменяет полномочия INSERT и DELETE К таблице DEPARTMENT у всех пользователей:

REVOKE SELECT, INSERT, UPDATE

ON DEPARTMENT

FROM PUBLIC;

После выполнения этого оператора привилегии INSERT и DELETE К таблице DEPARTMENT сохраняются у владельца этой таблицы и у пользователя SYSDBA, равно как и у имевших эти привилегии хранимых процедур, просмотров и триггеров. Отмена привилегий у PUBLIC также не убирает привилегии у пользователей, которые имеют их как собственные права.

Для отмены права у пользователя предоставлять конкретную привилегию, но сохранить у него эту привилегию, используйте REVOKE GRANT OPTION:

REVOKE GRANT OPTION

FOR <���привилегия> [, <���привилегия> [,...]]

ON <���таблица> | <���объект>

FROM <���пользователь> ;

Например, следующий оператор отменяет право предоставлять привилегию SELECT к таблице DEPARTMENT у пользователя HPOTTER и сохраняет у него привилегию SELECT:

REVOKE GRANT OPTION

FOR SELECT

ON DEPARTMENT

FROM HPOTTER;

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

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

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

С появлением в Firebird 1.5 оператора EXECUTE PROCEDURE, который позволяет нам обойти невозможность в Firebird выполнения операторов DDL в PSQL, мы можем выполнить групповую загрузку полномочий прямо в базу данных из хранимой процедуры. Пример подобной процедуры представлен в листинге 35.2 далее в этой главе.

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

Автор предпочитает генерировать скрипт безопасности. Он может быть протестирован и аннотирован, он является документом, нужным для контроля качества, и дающим основу для распространения у пользователей. Пример подобного скрипта представлен в листинге 35.1.