Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ
Шрифт:
Хотя кажется, что PUBLIC (т. е. все) имеют доступ ALL К системным таблицам, тем не менее существует таинственный черный ход в управлении правами SQL, который может легко исправить ситуацию. Вы можете ограничить доступ к системным таблицам, так же, как и к любым другим таблицам базы данных, предоставив, а затем отменив полномочия. При этом права предоставляются только для того, чтобы быть отмененными.
Все, что нужно сделать, - это просто установить управление доступом к системным таблицам путем выполнения серии операторов GRANT ALL <системная таблица> то PUBLIC. После этого мы можем отменить любые права.
Я не знаю точного технического объяснения, каким именно образом это работает, но это
Следует помнить некоторые вещи.
• Эта установка не сохраняется после восстановления базы данных из резервной копии, следовательно, напишите скрипт, который вы будете использовать каждый раз для только что восстановленной базы данных.
• Вам нужно быть внимательным по поводу удаления прав 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
Привилегия | Доступ |
SELECT | Чтение данных |
INSERT | Создание новых строк |
UPDATE | Изменение существующих данных |
DELETE | Удаление строк |
REFERENCES | Ссылка на первичный ключ из внешнего ключа. Это всегда необходимо делать при предоставлении привилегий к таблицам, содержащим внешние ключи |
ALL | Выборка, добавление, изменение, удаление и ссылка на первичный ключ из внешнего ключа |
EXECUTE | Выполнение хранимой процедуры или вызов ее с использованием SELECT. Эта привилегия никогда не предоставляется как часть привилегии ALL (см. разд. "Ключевое слово ALL") |
ROLE | Предоставляет все привилегии, назначенные роли. Если роль существует и имеет назначенные ей привилегии, она становится |
Упаковка привилегий
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 <mix-rpynna> в операторах GRANT и REVOKE.
Объекты
"Другой частью" полномочий является объект, к которому применяется привилегия или для которого она отменяется. Объектом может быть таблица, просмотр, хранимая процедура или роль, хотя не все привилегии применимы ко всем типам объектов. Например, привилегия UPDATE неприменима к процедуре, а привилегия EXECUTE - к таблице или просмотру.
Не существует "пакета объектов", который включает все или группу объектов. Должен быть, по крайней мере, один оператор GRANT для каждого объекта базы данных.
Ограничения привилегий
Привилегии SELECT, INSERT, UPDATE и DELETE применимы только к объектам, являющимся таблицами или просмотрами, REFERENCES применяется только к таблицам - точнее к тем, на которые ссылаются внешние ключи.
В случае просмотров пользователь должен иметь привилегии к самому просмотру, однако и полномочия к базовым таблицам должны быть предоставлены так или иначе. Правило гласит, что для владельца просмотра, для самого просмотра или для пользователя просмотра должны быть предоставлены соответствующие привилегии к базовым таблицам. Не имеет значения, как были получены привилегии, однако одно из трех должно быть выполнено.