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

Вопросы безопасности сервера

Любая библиотека встроенного сервера, размещенная на машине, где находится и база данных, потенциально является Троянским конем. На уровне сервера средства безопасности оперируют в предположении, что любой пользователь, соединяющийся с базой данных, будет идентифицироваться через базу данных безопасности security.fdb. Однако, когда встроенный сервер подключает клиента, идентификация пользователя с его паролем пропускается. Поскольку любой пользователь способен соединиться с любой базой данных, безопасность сервера будет легко отменена, если только серверная машина не будет защищена физически.

Можно написать приложение встроенного сервера, которое "соединится как пользователь SYSDBA", используя вообще что угодно в качестве пароля SYSDBA. Не существует никакого способа, чтобы сервер сообщил, что пользователь SYSDBA "прошел через стеклянный потолок" без допустимого пароля. Если SYSDBA активен в любой базе данных, то этот пользователь сможет соединяться и вытворять все, что ему захочется без каких-либо ограничений. Любой, кто имеет доступ к вашей сети и имеет привилегии к файловой системе на сервере, может установить злонамеренное приложение встроенного сервера, которое сможет читать и писать любые данные в ваши базы данных или вовсе их удалить.

Помните, что база данных безопасности (security.fdb) является такой же базой данных, как и другие. Пользователь SYSDBA имеет к ней специальные привилегии SQL - как и ко всем базам данных - для создания, модификации и удаления чего угодно.

Подготовленная машина для баз данных защищена от физических вторжений и неавторизованного доступа к файловой системе, "вошедший" в базу данных пользователь, не являющийся SYSDBA, будет субъектом обычных ограничений привилегий SQL. Привилегии SQL к объектам данных в базах данных Firebird применяются на основе "участия" - никакой пользователь, за исключением SYSDBA и владельца базы данных, не имеет автоматических прав к любым объектам любых баз данных.

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

См. главы 34 и 35 по вопросам безопасности доступа к серверу и привилегиям SQL к объектам базы данных.

Совместимость нескольких серверов

Любое количество приложений встроенного сервера может выполняться одновременно без каких бы то ни было конфликтов. Однако невозможно нескольким встроенным серверам иметь одновременный доступ к одной базе данных по причине блокировки, применяемой в архитектуре Суперсервера при первом успешном подключении.

Обычные серверы Firebird и InterBase могут без конфликтов одновременно выполняться на машине, на которой запущены встроенные серверы. Для доступа локального клиента следует обратить внимание на исключение конфликта пространства имен между обычными клиентскими библиотеками (gds32.dll и fbclient.dll) и именем, выбранным для библиотеки встроенного сервера.

"Клиентская" часть fbembed.dll может быть обычным, удаленным клиентом других серверов; в то же самое время она внутренне связывается со своим встроенным сервером.

Останов встроенного сервера

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

Модули внешних кодов

Firebird может расширить свои возможности путем доступа к определенным пользователям подпрограммам, написанным на включающем языке программирования и скомпилированным во внешние библиотеки общего доступа. Этот раздел содержит рассмотрение некоторых вопросов и техник, относящихся к написанию внешних функций (UDF) и фильтров BLOB.

* Внешние функции: Firebird "путешествует налегке" в отношении встроенных функций. Вместо того чтобы навешивать на сервер огромную библиотеку скрытых функций, Firebird позволяет разработчикам выбрать - и, при необходимости, определить- их собственные библиотеки внешних функций, которые соответствуют потребностям вычислений и выражений в их базах данных. Функции, определенные пользователем (User-Defined Function, UDF), добавляют высокую гибкость в среду вашей базы данных. UDF являются расширением функций сервера Firebird на серверной стороне; они объявляются для баз данных и выполняются в контексте серверного процесса.

Как и стандартные встроенные функции SQL, UDF могут быть разработаны для выполнения конвертирования данных или для вычислений, которые сложно или вообще невозможно выполнить в языке SQL. UDF включают функции для статистики, строк, дат и математических вычислений.

В разд. "Внешние функции" главы 21 подробно объясняется, как размешать, объявлять и использовать внешние функции, а также как сконфигурировать их размещение в файловой системе, чтобы исключить некоторые риски безопасности и целостности, существующие при выполнении внешнего кода вместе с ядром сервера. Конфигурация по умолчанию и режимы файловой системы также обсуждались ранее в этой главе при рассмотрении параметров udfAccess (версия 1.5) и externaI_fiIe_directory (версия 1,0.x).

* Фильтры BLOB: сервер Firebird использует несколько внутренне определенных подпрограмм для преобразования байтовых потоков из одного формата в другой. Эти подпрограммы называются фильтрами BLOB. Обработчик SQL представляет их в DDL и в метаданных в виде подтипов BLOB. Существует также возможность писать свои собственные фильтры BLOB для преобразования данных BLOB из одного формата в другой совместимый формат. Например, фильтр BLOB может конвертировать формат XML в формат RTF или изображение BMP в JPEG.

Разработка ваших собственных UDF

Библиотеки UDF компилируются как стандартные библиотеки совместного использования и выполняются на сервере, где размещена база данных. Библиотеки динамически загружаются базой данных во время выполнения, когда на библиотеку ссылается выражение SQL. Вы можете создавать библиотеки UDF на любой платформе, которая поддерживается в Firebird. Для использования одного и того же набора библиотек UDF в базах данных, выполняющихся на различных платформах, создайте и скомпилируйте отдельные библиотеки для каждой платформы, где располагается база данных.

Библиотека в этом контексте является совместно используемым объектом, который обычно имеет расширение dll на платформе Windows, расширение so для UNIX и Solaris и расширение si на HP-UX. Она может содержать одну или более точек входа для функций, определенных пользователем.

! ! !

СОВЕТ. Каталог Firebird /examples содержит некоторые старые примеры make- файлов (makefile.be и makefile.msc для систем Windows, makefile для UNIX), которые создают библиотеку ib_udf function из ib_udf.c.

. ! .

Процесс создания UDF состоит из четырех шагов:

1. Напишите функцию на любом языке программирования, который может создавать библиотеки совместного использования. Функция может принимать ограниченное количество входных параметров, но она должна возвращать один и только один результат. Функции, написанные на Java, не поддерживаются.

2. Скомпилируйте функцию и свяжите с динамически связываемой библиотекой (DLL) или с библиотекой совместно используемых объектов (SO) в соответствии с платформой.

3. Поместите библиотеку и любые требуемые символические ссылки в подходящее место на диске на серверной машине так, чтобы сервер мог получить к ней доступ в каталог по умолчанию /UDF или в альтернативный каталог, который вы сконфигурировали для библиотек внешних функций.

4. Используйте DECLARE EXTERNAL FUNCTION для объявления каждой индивидуальной UDF для каждой базы данных, в которой вам нужно ее использовать.

! ! !

ПРИМЕЧАНИЕ. Очень хорошей практикой является создание скрипта, содержащего объявления ваших UDF и некоторых комментариев, объясняющих использование.

. ! .

Написание модуля функции

На языке С UDF пишутся как любые стандартные функции. UDF может получать до десяти входных параметров и должна возвращать одно и только одно значение данных в качестве результата.

Исходный код модуля может определять одну или более функций. Если вы включите заголовочный файл Firebird ibase.h в ваш каталог Firebird /include при компиляции, ваш модуль С или C++ сможет использовать имеющиеся в нем определения типов (typedef). Возможности трансляции существуют и для других языков, включая Delphi. Например, исходный пакет для FreeUDFLib[143] от Gregory Deatz включает ibase.pas.

Параметры, не являющиеся BLOB или массивами, передаются функциям UDF либо по ссылке[144] с использованием типов данных включающего языка, допускающих преобразование в соответствующие типы данных Firebird, либо через дескриптор, используя предварительно определенную структуру, которая описывает тип данных Firebird во включающем языке. Может быть принято до десяти параметров, соответствующих любому типу данных Firebird за исключением массива или элемента массива. Если UDF возвращает BLOB, то количество входных параметров ограничивается девятью.