Firebird РУКОВОДСТВО РАЗРАБОТЧИКА БАЗ ДАННЫХ

С возможностью при инсталляции Firebird 1.5 ограничивать местоположение внешних объектов, к которым может обращаться сервер, ситуация несколько улучшается. При этом риски не устраняются полностью- вы должны выполнить конкретные шаги по реализации этой возможности и созданию ограничений файловой системы операционной системы. Доступ по умолчанию к внешним файлам в инсталляторе установлен в NONE, и каталоги внешних функций ограничены деревом UDF. Ваша задача - позаботиться о системных ограничениях.

Системные таблицы, где Firebird хранит все метаданные, включая сами привилегии SQL, вовсе не защищены привилегиями SQL.

Совет, как наказать идиотов-пользователей и плохих парней

Мой уважаемый коллега Павел Цизар (Pavel Cisar) предложил прием устранения недостатка привилегий SQL по защите метаданных Firebird, когда идиоты- пользователи, минуя DDL, пытаются изменять метаданные в системных таблицах, внося в них беспорядок. Это также отражает злонамеренные попытки разрушить ваши метаданные с помощью скрипта. Вот данное решение.

Хотя кажется, что PUBLIC (т. е. все) имеют доступ ALL К системным таблицам, тем не менее существует таинственный черный ход в управлении правами SQL, который может легко исправить ситуацию. Вы можете ограничить доступ к системным таблицам, так же, как и к любым другим таблицам базы данных, предоставив, а затем отменив полномочия. При этом права предоставляются только для того, чтобы быть отмененными.

Все, что нужно сделать, - это просто установить управление доступом к системным таблицам путем выполнения серии операторов 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

Привилегия	Доступ
SELECT	Чтение данных
INSERT	Создание новых строк
UPDATE	Изменение существующих данных
DELETE	Удаление строк
REFERENCES	Ссылка на первичный ключ из внешнего ключа. Это всегда необходимо делать при предоставлении привилегий к таблицам, содержащим внешние ключи
ALL	Выборка, добавление, изменение, удаление и ссылка на первичный ключ из внешнего ключа
EXECUTE	Выполнение хранимой процедуры или вызов ее с использованием SELECT. Эта привилегия никогда не предоставляется как часть привилегии ALL (см. разд. "Ключевое слово ALL")
ROLE	Предоставляет все привилегии, назначенные роли. Если роль существует и имеет назначенные ей привилегии, она становится привилегией, которая может явно назначаться пользователям. Роль никогда не предоставляется как часть привилегии ALL

Упаковка привилегий