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 |
<список-пользователей> | <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.
Права REFERENCES к столбцам
Привилегия REFERENCES является необходимым дополнением при предоставлении полномочий к таблице, у которой есть внешний ключ. Она нужна, если пользователь, создающий внешний ключ в таблице, не владеет таблицей, на которую ссылается этот ключ.
REFERENCES предоставляет полномочия к столбцам. Должны быть включены все столбцы, на которые ссылается внешний ключ таблицы, к которой предоставляются права. Если оператор GRANT REFERENCES ссылается на таблицу без указания столбцов, то полномочия предоставляются к каждому столбцу. Столбцы, которые не указаны в связи между внешним ключом и первичным ключом главной таблицы, не включаются в привилегию.
Вы можете задать только ключевые столбцы и, возможно, сохранить некоторую избыточность, если первичная таблица содержит очень много столбцов. Если вы сделаете так, вы должны задать все связанные ключевые столбцы. Упрощенный синтаксис выглядит так:
GRANT REFERENCES
ON <первичная-таблица> [ (<ключевой-столбец>
[, <ключевой-столбец> [, . . . ] ] ) ]
ТО <пользователь>
[WITH GRANT OPTION] ;
Следующий пример предоставляет привилегии REFERENCES К таблице DEPARTMENTS пользователю CHALKY, позволяя CHALKY записывать внешний ключ, который ссылается на первичный ключ таблицы DEPARTMENTS, даже если он не владеет этой таблицей:
GRANT REFERENCES ON DEPARTMENTS (DEPT_NO) TO CHALKY;
! ! !
СОВЕТ. Если видимость ключей не является проблемой, предоставьте привилегии REFERENCES для PUBLIC
. ! .
Привилегии к объектам
Когда для триггера, хранимой процедуры или просмотра нужен доступ к таблице или просмотру, достаточно, чтобы владелец объекта, к которому требуется доступ, сам объект или пользователь, использующий триггер, процедуру или просмотр, имел необходимые полномочия.
С другой стороны, привилегии к таблице могут быть предоставлены процедуре, а не индивидуальным пользователям для повышения безопасности. Пользователю нужна только привилегия EXECUTE к процедуре, которая осуществляет доступ к таблице.
Хранимой процедуре, просмотру или триггеру иногда нужны привилегии для доступа к таблице или просмотру, которые имеют другого владельца. Для предоставления привилегий триггеру или хранимой процедуре включите соответствующее ключевое слово TRIGGER или PROCEDURE перед именем модуля.
В следующем примере процедуре COUNT_CHICKENS предоставляются полномочия INSERT к таблице PROJ_DEPT_BUDGET:
GRANTINSERTON PROJ_DEPT_BUDGETTO PROCEDURE COUNT_CHICKENS;
Для использования хранимой процедуры пользователям, триггерам или другим хранимым процедурам нужна к ней привилегия EXECUTE. ЕСЛИ просмотр выбирает выходные поля из хранимой процедуры выбора, просмотр должен иметь привилегию
EXECUTE, а не привилегию SELECT.
Упрощенный синтаксис выглядит следующим образом:
GRANT EXECUTE
ON PROCEDURE <имя-процедуры> TO <получатель>;
<получатель> = [ PROCEDURE <имя-процедуры> [, <имя-процедуры> [, ..]]] [ TRIGGER <имя-триггера> [, <имя-триггера> [, ...]]] [ VIEW <имя-просмотра> [, <имя-просмотра> [, ...]]] | <имя-роли> | <пользователь-или-список> | PUBLIC [WITH GRANT OPTION];
138
Все версии InterBase и Firebird имеют весьма своеобразное поведение: если выдан GRANT на UPDATE к столбцам явно, то успешно может быть выполнен только UPDATE всей таблицы, без указания ограничения WHERE. Таким образом, выдача GRANT на UPDATE к конкретным столбцам является совершенно бесполезной. -Прим. науч. ред.