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

. ! .

EXECUTE может применяться только для хранимых процедур. Роли никогда не предоставляются "для" какого-либо объекта.

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

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

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

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

Пользователь SYSDBA имеет особые права ко всем базам данных и их объектам, независимо от того, какой пользователь ими владеет [137] Сервер просто не проверяет никакие права доступа для пользователя SYSDBA. В частности, поэтому операции над множеством объектов в SQL производятся от имени SYSDBA чуть быстрее, чем от имени других пользователей. - Прим. науч. ред. . Более того, в операционных системах, где реализована концепция Суперпользователя, - пользователь с привилегиями root или locksmith, - такой пользователь также имеет полный доступ и деструктивные права ко всем базам данных и их объектам, если он соединяется под этим идентификатором. Подробности см. в разд. "Слабое место POSIX" главы 34.

Вначале создатель объекта, его владелец, является единственным пользователем, кроме SYSDBA и Суперпользователя, который имеет доступ к этому объекту (таблице, просмотру, хранимой процедуре или роли) и может позволять получать к нему доступ другим пользователям. Любой пользователь затем может запустить "цепочку" полномочий, предоставляя другим пользователям права назначать привилегии. Такое право может передаваться добавлением предложения WITH GRANT OPTION К полномочиям.

Похожим образом SYSDBA или владелец роли может уточнять привилегию роли, передавая ее пользователю как WITH ADMIN OPTION. При этом предполагается, что пользователь, который подключается с этой ролью, не наследует от роли права WITH GRANT OPTION. Подробности этого далее.

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

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

Настоятельно рекомендуется, чтобы базы данных, предназначенные для использования во встроенном сервере, были жестко защищены полномочиями. Пользователь встроенного сервера под Windows намеренно не идентифицируется, следовательно, не существует базы данных безопасности! Коль скоро не выполняется проверка пользователей по операторам GRANT, ТО операторы полномочий могут быть применены к "фальшивому пользователю" (т. е. вымышленное имя, которое использует ваше приложение для соединения с базой данных через встроенный сервер).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Привилегия 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] Все версии InterBase и Firebird имеют весьма своеобразное поведение: если выдан GRANT на UPDATE к столбцам явно, то успешно может быть выполнен только UPDATE всей таблицы, без указания ограничения WHERE. Таким образом, выдача GRANT на UPDATE к конкретным столбцам является совершенно бесполезной. -Прим. науч. ред. .