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

We use cookies. Read the Privacy and Cookie Policy

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

Привилегии доступа могут быть предоставлены к целой таблице или просмотру. Можно также ограничить привилегии UPDATE и REFERENCES указанными столбцами.

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

GRANT <привилегии>

ON [TABLE] <таблица> | <просмотр> [ <объект> <опустить предложение ON> ТО <типичный-пользователь>

[{WITH GRANT OPTION} | {WITH ADMIN OPTION}];

<привилегии> = <привилегия> | <список-привилегий> | <имя-роли> ( ALL

<привилегия> = INSERT | DELETE | UPDATE [(столбец [, столбец [,..]] ) ]

| REFERENCES [(столбец [, столбец [,..]] ) ] | EXECUTE

<список-привилегий> = [, привилегия [, <список-привилегий> [,...]]]

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

<объект> = <хранимая-процедура> | <роль-с-привилегиями>

<типичный-пользователь> - <пользователь> | PUBLIC |

<список-пользователей> | <UNIX-пользователь> |

GROUP <UNIX-rpynna> | <пользователь-объект>

<список-пользователей> = <пользователь>,

{<пользователь> | <список-пользователей>}

<пользователь-объект> - <роль> | <триггер> | <хранимая-процедура>

Здесь пользователь- обычно пользователь, определенный в таблице USERS В базе данных безопасности Firebird. Во всех сетях клиент-сервер в POSIX это также может быть учетная запись пользователя, которая находится в /etc/password на серверной и клиентской машине, или группа UNIX, находящаяся на обеих машинах в /etc/group. Для баз данных, используемых во встроенном сервере под Windows, допустим "фальшивый пользователь" (известный приложению).

Следующий оператор предоставляет некоторые привилегии к таблице DEPARTMENTS пользователю CHALKY:

GRANT SELECT, UPDATE, INSERT, DELETE ON DEPARTMENTS TO CHALKY;

Права UPDATE к столбцам

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

В следующем операторе все пользователи будут иметь полномочия на изменение для таблицы CUSTOMER, однако они смогут изменять только столбцы CONTACT FIRST,

CONTACT_LAST и PHONE_NO:

GRANT UPDATE (CONTACT_FIRST, CONTACT_LAST, PHONE_NO) ON CUSTOMER TO PUBLIC;

* Когда при предоставлении привилегии UPDATE используется список столбцов, множество полномочий сохраняется в системной таблице RDB$USER_PRIVILEGES, по одному для каждого столбца. Права могут предоставляться или отменяться для каждого столбца индивидуально[138].

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

Спасибо правилам привилегий SQL - "самая забавная штука от Marx Brothers", по словам коллеги - можно предоставлять как на уровне столбца, так и на уровне таблицы привилегии UPDATE и REFERENCES одному и тому же пользователю. Это может привести к путанице, если права пользователя на уровне столбца UPDATE или REFERENCES отменяются, а те же полномочия пользователя на уровне таблицы сохраняются.

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