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

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

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

Наконец, посмотрим, что происходит при смене привилегий владельца представления по отношению к таблицам, на которых основано это представление. Для простоты предположим, что представлениеVосновано на базовой таблицеT. Если во время созданияVтекущийauthID(будущий владелец представления) обладал по отношению кTпривилегиямиSELECTиINSERT, то он будет обладать этими привилегиями и по отношению кV¹⁷⁴⁾. Если впоследствии владелец представления получит по отношению кTдополнительные привилегии, то он (и всеauthID, которым передавались все привилегии –ALL PRIVILEGESдляV) получит те же привилегии дляV. Должно быть понятно, каким образом обобщается этот подход на случай, когда представление определяется над несколькими таблицами или представлениями.

Передача ролей

Для передачи ролей используется следующий вариант оператора GRANT:

GRANT role_name_commalist

TO { PUBLIC | authID_commalist } [ WITH ADMIN OPTION ]

[ GRANTED BY { CURRENT_USER | CURRENT_ROLE } ]

Как показывает синтаксис, оператор позволяет передавать произвольное число ролей произвольному числу authID(которые могут представлять собой идентификаторы пользователей или имена ролей). Как и в случае передачи привилегий, от данногоauthIDможно передавать только те роли, которые были получены этимauthIDс привилегией на дальнейшую передачу (WITH ADMIN OPTION). При включении в состав оператораGRANTразделаGRANTED BYможно явно указать, что роли передаются от имени текущего идентификатора пользователя или же текущего имени роли.

22.2.5. Изменение текущих идентификаторов пользователей и имен ролей

Как мы отмечали ранее в этом разделе, в SQL:1999 специфицированы некоторые операторы, позволяющие изменять текущий идентификатор пользователя и текущее имя роли SQL-сессии.