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

Все, что нужно сделать, - это просто установить управление доступом к системным таблицам путем выполнения серии операторов GRANT ALL <���системная таблица> то PUBLIC. После этого мы можем отменить любые права.

Я не знаю точного технического объяснения, каким именно образом это работает, но это мой совет. Оператор GRANT создает управляющий список доступа (Access Control List, ACL) для системной таблицы, который проверяется в коде. Какая-то ветвь в этом коде означает "предоставить всем все привилегии, если элемент ACL не найден для системной таблицы, иначе использовать ACL".

Следует помнить некоторые вещи.

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

• Вам нужно быть внимательным по поводу удаления прав SELECT у PUBLIC К некоторым системным таблицам, потому что функции API isc_biob_iookup_desc() и isc_array_iookup_bounds() зависят от этой возможности. От этого также могут зависеть некоторые инструментальные средства и библиотеки.

• Удаление прав записи в системные таблицы не ограничивает возможность их изменения обычным нормальным способом с использованием команд DDL. Предотвращается только бесполезная прямая корректировка системных таблиц.

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

Синтаксис разрешения доступа:

GRANT <���привилегия> ON <���объект>

ТО <���пользователь>;

привилегия, предоставленная пользователю к объекту, создает разрешение. Синтаксис для удаления разрешений:

REVOKE <���привилегия> ON <���объект>

FROM <���пользователь>;

Доступны некоторые варианты "центрального" синтаксиса. Мы рассмотрим их несколько позже.

Привилегия представляет разрешение выполнять операцию DML. В табл. 35.1 описываются привилегии SQL, которые могут быть предоставлены или удалены.

Таблица 35.1. Привилегии SQL

SQL Firebird реализует возможности упаковки множества привилегий для назначения индивидуальным получателям, спискам или специально сгруппированным пользователям. Это пакет ALL, разделенные запятыми списки и роли SQL.

Ключевое слово ALL

Ключевое слово ALL упаковывает привилегии SELECT, INSERT, UPDATE, DELETE и REFERENCES в одном назначении. Роли и привилегия EXECUTE не включены в пакет ALL.

Привилегии SELECT, INSERT, UPDATE, DELETE и REFERENCES также могут быть предоставлены или отменены поодиночке или в списках, разделенных запятыми. При этом в операторах, где предоставляются или отменяются привилегия EXECUTE или привилегия роли, нельзя предоставлять или отменять другие привилегии.

Роль создается в базе данных и доступна только в этой базе данных. Думайте о роли, как о емкости для набора привилегий. Когда емкость "заполнена" некоторыми привилегиями, она становится доступна - как привилегия - некоторым типам пользователей.

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

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

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

Firebird поддерживает группы UNIX на платформах POSIX. Если реализована идентификация на уровне системы, вы можете предоставлять привилегии группам UNIX. См. вариант то GROUP в операторах GRANT и REVOKE.

"Другой частью" полномочий является объект, к которому применяется привилегия или для которого она отменяется. Объектом может быть таблица, просмотр, хранимая процедура или роль, хотя не все привилегии применимы ко всем типам объектов. Например, привилегия UPDATE неприменима к процедуре, а привилегия EXECUTE - к таблице или просмотру.

Не существует "пакета объектов", который включает все или группу объектов. Должен быть, по крайней мере, один оператор GRANT для каждого объекта базы данных.

Привилегии SELECT, INSERT, UPDATE и DELETE применимы только к объектам, являющимся таблицами или просмотрами, REFERENCES применяется только к таблицам - точнее к тем, на которые ссылаются внешние ключи.

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

Естественно изменяемые просмотры также требуют полномочий SELECT, INSERT, UPDATE и DELETE к базовым таблицам. Если просмотры только для чтения становятся изменяемыми с помощью триггеров, то триггерам нужны полномочия к базовым таблицам в соответствии с операциями, определенными в событиях триггера.

! ! !

ПРИМЕЧАНИЕ. Для создания просмотра необходимо иметь полномочия SELECT К базовым таблицам. В тех редких случаях, когда любая из этих.привилегий SELECT отменяется после создания просмотра, она должна быть добавлена для самого просмотра или для пользователей этого просмотра.