22.2.6. Аннулирование привилегий и ролей

Если от имени некоторого authIDнекоторые привилегии или роли были переданы одному или нескольким другимauthID, то впоследствии первыйauthID(в сессии, где этотauthID

175 Кстати, стандарт полностью отдает на волю реализации способ того, каким образом сделать неопределенным значение текущего пользовательского идентификатора SQL-сессии.

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

Аннулирование привилегий

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

REVOKE [ GRANT OPTION FOR] privilege_commalist

ON privilege_object

FROM { PUBLIC | authID_commalist }

[ GRANTED BY { CURRENT_USER | CURRENT_ROLE } ]

{ RESTRICT | CASCADE }

Синтаксис конструкций privilege и privilege_object такой же, как для оператора GRANT. Общий смысл операции должен быть понятен из синтаксиса: у указанныхauthIDаннулируются указанные привилегии доступа к указанному объекту базы данных.

Первой важной особенностью оператора аннулирования привилегий является обязательность указания одного из ключевых слов RESTRICTилиCASCADE. Если в операторе содержитсяRESTRICT, то при выполнении операции система проверит, не передавалась ли какая-либо из указанных привилегий каким-либоauthIDот тогоauthID, у которого привилегия должна быть аннулирована (это вполне возможно, если ранее привилегия была передана с правом передачи). Если это действительно так, операция не выполняется; в противном случае указанные привилегии у указанныхauthIDаннулируются. Иначе говоря, при наличии ключевого словаRESTRICTне допускается, например, ситуация, показанная нарис. 22.2.

Рис. 22.2.Передача полученной привилегии

На этом рисунке authID1является владельцем объекта базы данных с именемobjectи, следовательно, обладает всеми привилегиями над этим объектом. Пунктирной стрелкой обозначена одна из подобных привилегийpr1. От имениauthID1привилегияpr1была переданаauthID2вместе с привилегией на ее дальнейшую передачу. Наконец, от имениauthID2привилегияpr1была переданаauthID3. Тогда операция аннулирования этой привилегии от имениauthID1уauthID2при наличии ключевого словаRESTRICTне будет выполнена успешно.

В той же ситуации привилегия была бы аннулирована для authID2(и дляauthID3), если бы в оператореGRANTприсутствовало ключевое словоCASCADE. В общем случае если выполняется операцияREVOKE...CASCADE, то указанные привилегии аннулируются у всехauthID, прямо или косвенно (через промежуточныеauthID) получивших привилегии от текущегоauthIDSQL-сессии, в которой выполняется данная операция.

Если в операторе содержится раздел GRANT OPTION FOR, но имеется ключевое словоRESTRICT, то указанные привилегии для указанныхauthIDне аннулируются, но у указанныхauthIDаннулируется привилегия передачи данных привилегий (операция должна успешно выполняться только при соблюдении обсуждавшихся ранее условий). Однако если в операторе одновременно содержатся иGRANT OPTION FOR, иCASCADE, то указанные привилегии аннулируются у всехauthID, которые прямо или косвенно (через промежуточныеauthID) получили привилегии от текущегоauthIDSQL-сессии, в которой выполняется данная операция.

Задание в операторе необязательного раздела GRANTED BYпозволяет явно указать, что должно использоваться в качестве текущегоauthID– текущий пользовательский идентификатор или текущее имя роли SQL-сессии. Если разделGRANTED BYв оператореREVOKEне содержится, то действия производятся от имени текущегоauthIDSQL-сессии (о том, как он определяется, см. выше).

Если текущий (или указанный) authIDне обладает ни одной из указанных в оператореREVOKEпривилегий, то выполнение операции не производится (фиксируется ошибка). ЕслиauthIDобладает некоторыми, но не всеми, привилегиями из числа указанных, то операция выполняется по отношению к этим некоторым привилегиям, но выдается предупреждение.

Возможны ситуации, когда у некоторого authIDостается некоторая привилегия после выполнения операции аннулирования у этогоauthIDэтой привилегии. Одна из таких ситуаций проиллюстрирована нарис. 22.3.

Рис. 22.3.Косвенная и прямая передача привилегий

Здесь привилегия pr1передана отauthID1кauthID2вместе с правом на дальнейшую передачу этой привилегии. Далее, привилегияpr1передается отauthID2кauthID3. И затем выполняется прямая передача привилегии отauthID1кauthID3(на самом деле, порядок таких действий не является существенным). Теперь предположим, что от имениauthID1выполняется операция

REVOKE pr1 ON object FROM authID2 CASCADED

В соответствии с правилами SQL:1999 после выполнения этой операции authID3будет продолжать владеть привилегиейpr1по отношению к объектуobject, поскольку получил данную привилегиюдвумя разными способами. Грубо говоря, операцияREVOKE, выполняемая от имениauthID1, выполняется только по тем путям графа идентификаторов авторизации и объектов базы данных, которые начинаются с узлов, соответствующихauthID, указанных в разделеFROMэтой операции.

Далее, напомним, что если при передаче от authID1кauthID2привилегии на выполнение некоторых действий над некоторой таблицейT(например,UPDATE) явно не указывается список имен столбцов этой таблицы, то привилегия распространяется на все столбцы этой таблицы (включая столбцы, которые, возможно, еще будут созданы). Если действительно использовался такой способ передачи привилегий, то в дальнейшем можно аннулировать привилегиюauthID2на модификацию отдельных (уже определенных) столбцов таблицыT, оставив привилегию на модификацию всех остальных столбцов (включая те, которые еще не созданы).

И последнее замечание. Если некоторая привилегия была передана псевдоauthIDPUBLIC, то, конечно, этой привилегией обладают всеauthID. Но нет возможности аннулировать такую привилегию у отдельно указываемогоauthID. Привилегия была передана всем, и аннулировать ее можно только сразу у всех.