Привилегии
Привилегия представляет разрешение выполнять операцию DML. В табл. 35.1 описываются привилегии SQL, которые могут быть предоставлены или удалены.
Таблица 35.1. Привилегии SQL
Привилегия |
Доступ |
SELECT |
Чтение данных |
INSERT |
Создание новых строк |
UPDATE |
Изменение существующих данных |
DELETE |
Удаление строк |
REFERENCES |
Ссылка на первичный ключ из внешнего ключа. Это всегда необходимо делать при предоставлении привилегий к таблицам, содержащим внешние ключи |
ALL |
Выборка, добавление, изменение, удаление и ссылка на первичный ключ из внешнего ключа |
EXECUTE |
Выполнение хранимой процедуры или вызов ее с использованием SELECT. Эта привилегия никогда не предоставляется как часть привилегии ALL (см. разд. "Ключевое слово ALL") |
ROLE |
Предоставляет все привилегии, назначенные роли. Если роль существует и имеет назначенные ей привилегии, она становится привилегией, которая может явно назначаться пользователям. Роль никогда не предоставляется как часть привилегии ALL |
Упаковка привилегий
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 применяется только к таблицам - точнее к тем, на которые ссылаются внешние ключи.
В случае просмотров пользователь должен иметь привилегии к самому просмотру, однако и полномочия к базовым таблицам должны быть предоставлены так или иначе. Правило гласит, что для владельца просмотра, для самого просмотра или для пользователя просмотра должны быть предоставлены соответствующие привилегии к базовым таблицам. Не имеет значения, как были получены привилегии, однако одно из трех должно быть выполнено.
Естественно изменяемые просмотры также требуют полномочий SELECT, INSERT, UPDATE и DELETE к базовым таблицам. Если просмотры только для чтения становятся изменяемыми с помощью триггеров, то триггерам нужны полномочия к базовым таблицам в соответствии с операциями, определенными в событиях триггера.
! ! !
ПРИМЕЧАНИЕ. Для создания просмотра необходимо иметь полномочия SELECT К базовым таблицам. В тех редких случаях, когда любая из этих.привилегий SELECT отменяется после создания просмотра, она должна быть добавлена для самого просмотра или для пользователей этого просмотра.
. ! .
EXECUTE может применяться только для хранимых процедур. Роли никогда не предоставляются "для" какого-либо объекта.
Пользователи
Пользователи являются получателями полномочий; они теряют их, когда полномочия отменяются. Пользователь может быть пользователем, определенным в базе данных безопасности, учетной записью или группой UNIX, специальным пользователем или объектом базы данных.
* Роли в качестве пользователей: когда роли назначены привилегии, она становится пользователем. Когда роль получает требуемые привилегии к объектам, она изменяет свой статус и становится привилегией, которая может быть предоставлена некоторым другим типам пользователей. Когда происходит подключение к базе данных под этой ролью, такие пользователи получают все привилегии, которые были предоставлены этой роли.
* Просмотры в качестве пользователей: просмотрам нужны полномочия для доступа к таблицам, другим просмотрам и к хранимым процедурам.
* Процедуры и триггеры в качестве пользователей: хранимой процедуре, которая обращается к таблицам и просмотрам и выполняет другие процедуры, нужны полномочия к этим объектам. Триггеру, который выполняет процедуры, нужны к ним полномочия, а также к любым таблицам и просмотрам, к которым он обращается, отличным от той таблицы, которой он принадлежит.
Специальные пользователи
Пользователь SYSDBA имеет особые права ко всем базам данных и их объектам, независимо от того, какой пользователь ими владеет[137]. Более того, в операционных системах, где реализована концепция Суперпользователя, - пользователь с привилегиями root или locksmith, - такой пользователь также имеет полный доступ и деструктивные права ко всем базам данных и их объектам, если он соединяется под этим идентификатором. Подробности см. в разд. "Слабое место POSIX" главы 34.
Вначале создатель объекта, его владелец, является единственным пользователем, кроме SYSDBA и Суперпользователя, который имеет доступ к этому объекту (таблице, просмотру, хранимой процедуре или роли) и может позволять получать к нему доступ другим пользователям. Любой пользователь затем может запустить "цепочку" полномочий, предоставляя другим пользователям права назначать привилегии. Такое право может передаваться добавлением предложения WITH GRANT OPTION К полномочиям.
Похожим образом SYSDBA или владелец роли может уточнять привилегию роли, передавая ее пользователю как WITH ADMIN OPTION. При этом предполагается, что пользователь, который подключается с этой ролью, не наследует от роли права WITH GRANT OPTION. Подробности этого далее.
Пользователь PUBLIC
137
Сервер просто не проверяет никакие права доступа для пользователя SYSDBA. В частности, поэтому операции над множеством объектов в SQL производятся от имени SYSDBA чуть быстрее, чем от имени других пользователей. - Прим. науч. ред.