Роли SQL: пользователи и безопасность в InterBase

Brett Bandy, Markus Kemper, BorCon, 1998.

Перевод: Григорий Сапунков.
Редакция, примечания, ссылки: KDV.
26 августа 2003
Оригинал статьи: http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_sqlroles или http://community.borland.com/article/interbase/sqlroles.pdf

Базы данных, как и данные, хранимые в файлах базы данных, должны быть защищены. InterBase обеспечивает двухуровневую защиту данных – аутентификация пользователя на уровне сервера и привилегии на уровне базы данных. В данном документе рассказывается, каким образом управлять безопасностью вашей базы данных на каждом из уровней. Рассматриваемые вопросы:

• Пользователь InterBase и способы его создания
• Основы привилегий SQL и их применение
• Как роли SQL могут облегчить жизнь администратора базы данных?
• Как использовать роли SQL?

 

Что такое пользователь InterBase?

Безопасность InterBase основана на концепции "пользователя" (user). Безопасность всей базы данных, в сущности, зависит от проверки подлинности идентификатора пользователя. Информация о пользователях , зарегистрированных для конкретного сервера InterBase, хранится в особой базе данных безопасности (security database) – ISC4.GDB (из-за проблем с резервированием файлов с расширением gdb в Windows XP в IB7 этот файл переименован в ADMIN.IB, в FB1.5 – в SECURITY.FDB. В обоих случаях для сервера можно указать иное имя). Для каждого сервера InterBase существует своя собственная база данных безопасности, таким образом, пользователь "привязан" к конкретному серверу. Пользователь с таким же именем может существовать на нескольких серверах, но для этого информация о нем должна быть заведена на каждом из серверов. В базе данных безопасности также для каждого пользователя хранится зашифрованное значение пароля. Пользователь, авторизованный на сервере, имеет доступ ко всем базам данных этого сервера.

Имя пользователя может состоять максимум из 31 символа, при этом их регистр не учитывается. Пароль может состоять максимум из 8 символов (если ввести больше, лишние символы игнорируются), регистр – учитывается.

KDV: механизм логина на сервере следующий – клиентская часть, принимая пароль пользователя, шифрует его алгоритмом DES с потерей данных (см. раздел www.ibase.ru/d_security.htmLINK), после чего передает зашифрованный пароль на сервер. Сервер, приняв пароль, шифрует его еще раз тем же алгоритмом, и сравнивает со строкой, хранящейся в таблице users базы isc4.gdb. Т. е. пароль никогда не дешифруется в исходный вид, и это сделать невозможно. Даже перехватив "полузашифрованный" пароль на этапе его пересылки с клиента на сервер единственным способом "взлома" остается только прямой подбор пароля.

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

Поле	Обязательно?	Тип	Описание
User Name	Yes	String	Имя пользователя, указываемое при подключении
Password	Yes	String	Пароль пользователя
UID	No	Integer	Необязательный UserID. В данный момент поле не используется
GID	No	Integer	Необязательный GroupID. В данный момент поле не используется
Full Name	No	String	Полное имя пользователя

 

Расширение списка пользователей InterBase пользователями ОС

Все версии InterBase используют базу данных безопасности для аутентификации пользователей, при этом некоторые версии позволяют организовать разграничение доступа на основе системы разграничения доступа операционной системы. Версии InterBase, работающие под управлением Unix, позволяют при подключении к серверу InterBase или его базам использовать либо учетные записи операционной системы, либо учетные записи InterBase. Версии, работающие под Win95 или NT, не позволяют использовать систему разграничения доступа этих операционных систем, соответственно, пользователи Win95 или NT не являются легальными пользователями InterBase. В данном случае,для аутентификации пользователей, InterBase полностью полагается на свою базу данных безопасности.

В случае с Unix, InterBase будет трактовать пользователя Unix точно так же как и пользователя, хранящегося в собственной базе данных InterBase, до тех пор, пока сервер видит клиента в качестве доверенного хоста. Учетные записи пользователя должны существовать как на клиенте, так и на сервере. Для того чтобы установить доверительные отношения с хостом клиента, необходимо на сервере занести соответствующую запись в файл /etc/hosts.equiv или /etc/gds_hosts.equiv. В файле hosts.equiv прописываются доверительные отношения на уровне операционных систем, которые, соответственно, распространяются на все сервисы (например, rlogin, rsh, rcp). В файле gds_hosts.equiv устанавливаются доверительные отношения между хостами, только для InterBase. Формат записи идентичен для обоих файлов, и выглядит следующим образом:
Нельзя устанавливать доверительные отношения между хостами под управлением Unix и Windows. Для того чтобы использовать учетные записи Unix, необходимо, чтобы и клиент и сервер функционировали под управлением Unix.

Системные учетные записи Unix используются если при установлении соединения с сервером InterBase не указывается имя пользователя.
 

Пользователь SYSDBA

После первоначальной установки InterBase в системе существует только один авторизованный пользователь – SYSDBA. SYSDBA – это специальная учетная запись, которая существует вне всех ограничений безопасности и имеет полный доступ ко всем базам данных сервера. По умолчанию пароль SYSDBA – masterkey (точнее – "masterke", как было сказано выше, длина пароля составляет 8 символов; более подробно см. баг #anchor_423810 [4]). Настоятельно рекомендуется сменить этот пароль, потому как любой, кто когда-либо пользовался InterBase, может легко "угадать" его. Только SYSDBA может добавлять, изменять и удалять других пользователей.
  В Unix системах пользователь root может выступать в роли SYSDBA. InterBase в этом случае будет трактовать имя пользователя root как SYSDBA, и вы будете иметь доступ ко всем базам данных сервера.

KDV: 10 января 2001 в исходных текстах IB 6.0 была обнаружена дыра в безопасности – вкомпилированный в код сервера username/password (politically/correct). Однако, пользователь зайдя под таким account ничего не может делать (только просматривать сист. таблицы). Кроме того, username должен быть введен в нижнем регистре, а подавляющее количество инструментария (99%) автоматически при вводе конвертируют username в верхний регистр. Для 5.6, 6.0, и FB 0.9.3 был выпущен патч (IBPhoenix, Embarcadero). В версии 6.0.1 и выше эта дыра закрыта.

 

Управление пользователями

InterBase предоставляет SYSDBA три интерфейса для управления пользователями:

• утилита командной строки GSEC
• графическая утилита Server Manager
• функции InterBase API (isc_add_user...)

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

KDV: сейчас ServerManager уже нет, и можно пользоваться IBConsole, IBExpert, GrantManager и т. п. – www.ibase.ru/d_security.htmLINK). Кроме этого добавился еще один способ – через Services API (который пока не полностью работает в версиях Classic (в FB 1.5.1 Classic уже работает), см. палитру InterBase Admin в Delphi/BCB и пример Admin в поставке).

KDV: в InterBase 7.5 введена возможность хранения учетных записей пользователей непосредственно в базе данных, без необходимости наличия admin.ib. Это позволяет не только обеспечивать контроль доступ пользователей для конкретной базы, но и организовывать комбинированные схемы для доступа разных пользователей к разным базам данных на одном и том же сервере. Управление пользователями в случае EUA (Embedded User Authentification) производится операторами SQL (что не поддерживается больше ни в каком сервере). См. статью.

 

Использование утилиты командной строки GSEC

GSEC – это утилита командной строки, обеспечивающая интерфейс к базе данных безопасности. Вы должны иметь права SYSDBA или суперпользователя (root для Unix), чтобы использовать GSEC. Данную утилиту можно использовать в интерактивном режиме или режиме командной строки. В таблице представлены допустимые команды GSEC.

Команда	Описание
di[splay]	Показывает информацию обо всех пользователях из базы ISC4.GDB
di[splay] name	Показывает информацию о пользователе name
a[dd] name -pw passwd [option argument option argument ...]	Добавляет пользователя с именем name, паролем passwd и дополнительной информацией
mo[dify] name [options]	Изменяет атрибуты пользователя
de[lete] name	Удаляет информацию о пользователе с именем name из ISC4.GDB
h[elp]	Показывает синтаксис команд GSEC
q[uit]	Завершает сеанс

Просмотр информации о пользователях

Команда DISPLAY отображает информацию обо всех известных пользователях:

Добавление пользователя

Чтобы добавить нового пользователя в базу данных безопасности необходимо использовать команду ADD.

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

Опция	Описание
-pw	Пароль пользователя
-u[id]	ID пользователя
-g[id]	ID группы
-f[name]	Имя пользователя (first name)
-mn[ame]	Отчество пользователя (middle name)
-l[name]	Фамилия пользователя (last name)

В следующем примере заводится пользователь BJONES с паролем "blah" и указываются его имя и фамилия:

Изменение информации о пользователе

Для изменения информации о существующем пользователе используется команда MODIFY. Следующий пример демонстрирует процесс модификации UserID и имени пользователя BJONES

Удаление пользователя

Данный пример демонстрирует, как можно с помощью команды DELETE удалить пользователя BJONES. Чтобы убедиться в успешности проделанной работы, используется команда DISPLAY, которая показывает список всех существующих пользователей:  

Использование InterBase API для управления пользователями

Начиная с версии 5.0 InterBase предоставляет собственный Application Programming Interface (API) для доступа к базе данных и осуществления административных функций. Помимо прочего в данном API имеются три функции, которые позволяют разработчику приложения реализовать администрирование пользователей.

KDV: далее описание функций isc_add_user, isc_modify_user, isc_delete_user и примеры удалены для сокращения объема статьи. Примеры на C см. в API Guide, примеры на Delphi – ibusers.zip. Пример использования всех InterBase Admin (services api) компонент – AdminDemo.

KDV: при использовании функций user api есть одна проблема – вы должны передавать в вызове username/password SYSDBA. Для приложений, которые дают возможность пользователям самим модифицировать свой пароль, это неприемлемо. Проблема решается только через модификацию ISC4.GDB: дается GRANT UPDATE ON USERS TO PUBLIC после чего на таблице users создается exception и триггер before update: if USER <> 'new.USER' then exception NOTALLOWED; Таким образом пользователю разрешается менять только свой, а не чужой пароль. Подробнее этот способ и другие модификации isc4.gdb описан в документе.

 

Логин по умолчанию

Существует возможность определить username/password, который будет использоваться клиентской частью (gds32.dll) по умолчанию. Это делается при помощи переменных среды ISC_USER/ISC_PASSWORD. Если вы укажете в этих переменных имя пользователя и пароль, то при "пустой" информации при логине к серверу будут использоваться именно эти имя и пароль.
Однако, не все инструменты или программы позволяют ввести пустой username.

Данными переменными среды удобно пользоваться для административных целей, например, при ремонте БД или других операциях, однако нужно учитывать интересную особенность – если эти переменные среды определены на серверной стороне, то клиент также может осуществить "логин по умолчанию" не указывая username/password! Поэтому, если вы и используете данную возможность, то определяйте переменные среды только для контекста пользователя, но не для всей системы (см. закладки User и System в MyComputer/Properties/Advanced/Environment variables).
 

Привилегии SQL: Второй уровень безопасности

Как уже отмечалось, в InterBase реализована двухуровневая модель безопасности. На первом уровне осуществляется аутентификация пользователя в момент подключения к базе данных, при этом используется база данных безопасности (более подробно см. предыдущий раздел). Второй уровень реализуется уже на уровне самой базы данных. Все привилегии по доступу к объектам базы данных хранятся в самой базе. Авторизованный пользователь не имеет никаких привилегий по доступу к данным, хранящимся в базе, пока какие-либо права не будут ему предоставлены явным образом. Контроль привилегий осуществляется на уровне таблиц. Каждому пользователю сопоставлен список операций, которые допускается произвести над данной таблицей или представлением. Этот список и составляет привилегии пользователя. Возможность использования хранимых процедур в InterBase регулируется отдельной привилегией. Право на доступ к любому объекту базы данных после его создания имеют только SYSDBA и владелец этого объекта. Владельцем объекта является пользователь создавший этот объект. SYSDBA или владелец объекта могут выдавать привилегии другим пользователям, в том числе и привилегии на право выдачи привилегий другим пользователям. Собственно сам процесс раздачи привилегий на уровне SQL реализуется двумя операторами: GRANT и REVOKE. Оператор GRANT выдает привилегии авторизованным пользователям на доступ к таблицам или представлениям, а оператор REVOKE, соответственно, изымает ранее выданные привилегии.

Распространенная ошибка: Очень часто разработчики создают объекты в базе данных и забывают назначить привилегии каким-либо пользователям. Учитывая, что сам разработчик является владельцем этих объектов, у него не возникает каких-либо проблем с привилегиями на доступ к ним. Когда же приходит время внедрять приложение, пользователи получают отказ в доступе к объектам, в связи с отсутствием назначенных привилегий.

Для всех операций, связанных с управлением безопасностью, SYSDBA всегда имеет права назначать и отменять привилегии пользователям. SYSDBA – это суперпользователь, которому невозможно отменить доступ к какому-либо объекту базы данных. Соответственно, операторы GRANT и REVOKE не имеют смысла в отношении пользователя SYSDBA.

Оператор GRANT

Оператор GRANT предоставляет привилегии на объект или привилегии указанному пользователю. В таблице представлен список привилегий, которые могут быть выданы пользователю.

Привилегия	Пользователь получает возможность...
Insert	Добавлять новые строки в таблицу
Update	Изменять данные в таблице
Delete	Удалять строки из таблицы
Select	Извлекать содержимое таблицы
Execute	Выполнить хранимую процедуру ( в том числе и как select)
References	Сервер может проверять внешние ссылки на другие таблицы
All	Делать все выше обозначенные, за исключением Execute

KDV: существование пользователя, которому выдаются права, не проверяются при выполнении оператора grant. Помните, что пользователи существуют в isc4.gdb. Права же в базе данных могут быть выданы каким угодно, в том числе несуществующим (пока или по ошибке) пользователям.

Назначение привилегий пользователю PUBLIC

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

Назначение привилегий на выполнение хранимых процедур

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

KDV: начинающие пользователи часто опускают слово procedure думая что to name самостоятельно определит, что name – это имя процедуры. Это не так. При выдаче прав to name означает выдачу права именно пользователю, а не объекту вообще. Кроме того, существование таких пользователей не проверяется (они находятся в isc4.gdb).

KDV: при модификации процедур (alter) права, выданные им, сбрасываются.

KDV: права, выданные процедуре, проверяются сразу при ее загрузке в память для выполнения, а не по ходу выполнения процедуры. Это значит, что если в коде процедуры (или триггера) есть обращение к объекту при каком то условии (if ...then), то права на этот объект должны быть даны процедуре обязательно. В противном случае при выполнении процедуры сразу будет выдана ошибка о нехватке прав, даже если по всем условиям данная ветка if не выполняется.

Назначение привилегий для представлений

В основном, процесс назначения привилегий для представлений соответствует аналогичному процессу для таблиц. Но, имеются некоторые особенности, которые хотелось бы отметить. Необходимо помнить, что представление это своего рода "виртуальная" таблица, представляющая собой запрос в базовую таблицу. Данные, извлекаемые по этому запросу, не хранятся в представлении. В самом представлении храниться только описание запроса, соответственно, любой запрос типа INSERT, UPDATE или DELETE предполагает модификацию базовой таблицы. Поэтому, привилегии типа INSERT, UPDATE или DELETE имеет смысл выдавать только для обновляемых представлений. В общем случае, обновляемое представление – это представление, в запросе которого не используются агрегатные функции и нет соединений (более подробно, например, см. [2]). Хотя и разрешается выдавать привилегии INSERT, UPDATE, или DELETE на представления только для чтения без каких-либо сообщений об ошибке, любая попытка изменения данных через такое представление успеха не достигнет. Привилегию SELECT для доступных только на чтение представлений можно использовать, например, с целью контроля доступа за тем, какие конкретно пользователи могут извлекать из него данные.

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

Например, представим себе таблицу TEST_SCORES, содержащую поля LASTNAME, FIRSTNAME, TESTNAME, SCORE. Столбцы LASTNAME, FIRSTNAME и TESTNAME таблицы содержат информацию, доступную для всех пользователей – в них хранится информация о том, кто проходил какие тесты. Но есть также информация, которую не следовало бы делать доступной для всех категорий пользователей – поле SCORE (результаты). Соответственно, необходимо обеспечить всем пользователям доступ к определенному набору полей таблицы TEST_SCORES, и только некоторым избранным ко всем полям, включая и поле SCORE. Это можно реализовать, создав представление, на основе запроса, выбирающего необходимый набор полей, доступный для каждого пользователя, и выдав привилегии всем пользователям на доступ только к этому представлению, а не к таблице:

KDV: механизм выдачи прав на view несколько отличается от других прав, выдаваемых объектам. Например, не требуется выдавать право view на доступ к таблице, к которой обращается view.

Примеры использования оператора GRANT

В этом примере выдается привилегия ALL для таблицы TEST_SCORES пользователю JJOHNSON. Привилегия ALL дает право пользователю выполнять операции insert, update, select, delete с указанной таблицей:
Следующий пример, иллюстрирует выдачу привилегии ALL специальному пользователю PUBLIC. Пользователь PUBLIC назначает всем существующим и будущим пользователям привилегию ALL для таблицы TEST_SCORES:
А в этом примере привилегия ALL выдается хранимой процедуре на доступ к таблице TEST_SCORES. Пользователям, для того, чтобы они могли использовать эту процедуры, необходимо выдать привилегию EXECUTE для этой процедуры (см. далее):
В этом примере специальному пользователю PUBLIC предоставляется привилегия EXECUTE, что позволит всем существующим и добавленным позже пользователям запускать процедуру. В свою очередь процедура должна иметь все необходимые привилегии по доступу к используемым таблицам:
Пример выдачи привилегии INSERT для таблицы TEST_SCORES пользователю JJOHNSON. Пользователь JJOHNSON сможет добавлять новые записи в таблицу, но не сможет просматривать данные (т. е. применить select к этой таблице):
Пример предоставления привилегии UPDATE на набор конкретных столбцов пользователю JJOHNSON. Пользователь сможет обновлять данные только в столбцах, указанных в команде:

Предоставление прав с GRANT OPTION

Изначально, как уже говорилось, только SYSDBA и владелец объекта могут предоставлять привилегии другим пользователям. Предложение WITH GRANT OPTION оператора выдачи привилегии позволяет SYSDBA или владельцу предоставить право пользователю передавать полученные привилегии другим пользователям. Учитывая, что оператор предоставления привилегий применяется единовременно только к одной таблице, предложение WITH GRANT OPTION также может быть применимо для одной таблицы в одной команде. Соответственно, оператор GRANT с предложением WITH GRANT OPTION необходимо применить для каждой таблицы, по отношению к которой у SYSDBA или её владельца есть желание передать бразды правления другим пользователям. Пользователь, которому дали право выдавать привилегии, может назначать только те привилегии, которыми он обладает сам. Т. е., к примеру, если пользователю предоставили разрешение на чтение таблицы, то он не сможет передать право, скажем, на изменение этой таблицы другому пользователю. В примере пользователю BJONES предоставляется право доступа к таблице employee с использованием оператора SELECT, а также разрешается выдавать эту привилегию другим пользователям:
Пользователь, получивший право передавать свою привилегию другим пользователям, может также передать и само право передачи привилегии. Соответственно, если оставить ситуацию без контроля, то могут возникнуть проблемы с безопасностью базы данных. Учитывая, что нет возможности предоставить пользователю право назначать привилегии другим пользователям без предоставления возможности передачи им самого этого права другим пользователям, необходимо разумно использовать предложение WITH GRANT OPTION.

Оператор REVOKE

Если оператор GRANT позволяет назначать привилегии пользователям, то оператор REVOKE позволяет отменить назначенные привилегии. При этом следует учитывать, что отменить можно только ранее назначенные права доступа. Синтаксис оператора отмены привилегий имеет следующий вид:
Только тот пользователь, который выдавал ранее привилегию, может удалить её. Например, если пользователь А предоставил какую-либо привилегию пользователю Б, то пользователь В не сможет отнять её у пользователя Б. Только у пользователя А имеется такое право. Пользователь SYSDBA всегда может предоставить и/или отменить любую привилегию любому пользователю.

Привилегия ALL объединяет привилегии SELECT, INSERT, UPDATE, DELETE и может использоваться для упрощения отмены множества привилегий пользователя. Для того, чтобы использовать аргумент ALL в выражении отмены прав, необязательно, чтобы пользователь обладал всеми привилегиями, включаемыми в ALL. При отмене привилегии ALL, он потеряет подмножество привилегий ALL. Например, предположим, что пользователь имеет привилегии INSERT и SELECT, и если SYSDBA выполнит команду REVOKE ALL для данной таблицы, то пользователь больше не будет иметь какие-либо права для этой таблицы.

Выше уже объяснялось, что предложение WITH GRANT OPTION предоставляет право передавать другим пользователям назначаемые привилегии. Пользователь, получивший такое право, может в свою очередь, передать возможность передачи прав другим пользователям. Это может привести к образованию дыр в системе разграничения доступа базы данных. Начиная с того, что только несколько пользователей имеют права предоставления привилегий, очень быстро можно прийти к ситуации, когда уже огромное число пользователей обладают такими возможностями. Для того, чтобы остановить рост своеобразного кома, можно воспользоваться командой отмены привилегий. Отмена привилегий пользователю, предоставленных ему с GRANT OPTION, приводит к тому, что и все другие пользователи, получившие эти привилегии от данного пользователя, также теряют их. Следующая последовательность поясняет сказанное:

1. Предоставление привилегий пользователю USERA с GRANT OPTION
2. Пользователь USERA передает права пользователю USERB
3. Отмена привилегий пользователя USERA
4. Ни пользователь USERA, ни USERB не имеют привилегий

Последовательность команд GRANT и REVOKE демонстрирующих рассмотренный сценарий:

Connect to database as SYSDBA:
  GRANT ALL ON TEST_SOURCE TO USERA WITH GRANT OPTION;
Connect to database As USERA:
  GRANT ALL ON TEST_SOURCE TO USERB;
Connect to database as SYSDBA:
  REVOKE ALL ON TEST_SOURCE FROM USERA;
Connect to database as USERA:
  SELECT * FROM TEST_SOURCE;
  Statement failed, SQLCODE = -551
  no permission for read/select access to table TEST_SOURCE
Connect to database as USERB:
  SELECT * FROM TEST_SOURCE;
  Statement failed, SQLCODE = -551
  no permission for read/select access to table TEST_SOURCE

Отмена привилегий пользователя PUBLIC

Если пользователю PUBLIC были назначены какие-либо привилегии, тогда их уже нельзя отменить для какого-то одного конкретного пользователя. Специальный пользователь PUBLIC используется, когда необходимо предоставить доступ к таблице любому пользователю. Однако, не следует на него смотреть как на группу пользователей. Когда пользователю PUBLIC предоставили привилегии, то и отменить их можно будет у него же (т. е. либо всем, либо никому). Предположим, например, что пользователю PUBLIC выдали привилегию ALL на таблицу TEST_SOURCE, в этом случае пользователь SYSDBA не сможет отдельно отменить эту привилегию для пользователя BJONES. Если требуется, чтобы только определенная группа пользователей имела доступ к таблице, тогда не следует предоставлять прав пользователю PUBLIC для этой таблицы. 

Примеры использования оператора Revoke

Приведем пример отмены привилегии ALL пользователю PUBLIC. Данный оператор затронет только привилегии, которые непосредственно выдавались пользователю PUBLIC. Все другие привилегии, которые предоставлялись отдельным пользователям останутся в силе.

REVOKE ALL ON TEST_SOURCE FROM PUBLIC;

Этот пример отменяет привилегию INSERT пользователю BJONES, другие назначенные привилегии по отношению к этой таблице по прежнему остаются в силе.

REVOKE INSERT ON TEST_SOURCE FROM BJONES;

Отмена привилегии EXECUTE пользователя BJONES. После выполнение команды, пользователь BJONES не сможет использовать хранимую процедуру.

REVOKE EXECUTE ON PROCEDURE GET_PASSING_SCORES FROM BJONES;

Отмена привилегии, назначенной с GRANT OPTION

Оператор REVOKE также предоставляет возможность отмены права передачи привилегии другим пользователям. Следующий пример продемонстрирует отмену возможности пользователю BJONES передавать его привилегии другим пользователям, при этом пользователь BJONES всё ещё может сам использовать назначенные привилегии по отношению к этой таблице, но уже не сможет передать их другим.

REVOKE GRANT OPTION FOR ALL ON TEST_SOURCE FROM BJONES;

Можно также отменить GRANT OPTION для некоторых операций. Например, если BJONES имеет права на выдачу привилегии ALL, можно использовать команду REVOKE для отмены ему GRANT OPTION только для операции INSERT:

REVOKE GRANT OPTION FOR INSERT ON TEST_SOURCE FROM BJONES;

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

Низкая эффективность средств безопасности SQL

Стандартные средства разграничения доступа SQL (в данном документе под стандартом понимается стандарт SQL-92) позволяют ограничить доступ к данным, однако они недостаточно эффективны с точки зрения управления доступом к данным в целом. SQL ориентирован на работу с индивидуальным пользователем. За исключением пользователя PUBLIC, не имеется возможностей по управлению пользователями на групповом уровне. Более того, механизм привилегий требует, чтобы права назначались непосредственно для каждой таблицы базы данных.

Например, предположим, что администратору необходимо настроить привилегии по доступу к 100 таблицам для 100 пользователей базы данных. В общем случае, для каждого пользователя потребуется выполнить по одной команде на каждую из таблиц. Таким образом, требуется 100 команд только для одного пользователя и, соответственно, 10000 команд для всех пользователей. В команде GRANT для таблиц можно перечислить сразу несколько пользователей, но такой подход может привести ко многим ошибкам. Администратору базы данных потребуется каким-либо образом разделять пользователей между командами и учитывать, кому он уже выдал и какие привилегии к каждой из таблиц. В большинстве случаев, администраторы предпочитают выдавать права для каждого пользователя в отдельной команде. 

Трудности управления пользователями средствами безопасности SQL

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

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

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

Слабая гибкость средств безопасности SQL

Средства обеспечения безопасности стандартного SQL не обеспечивают гибкого управления правами пользователей, реализуя только принцип "либо всё, либо ничего". Либо у пользователя есть привилегия, либо её у него нет. Не имеется возможности по гибкому изменению пользовательских прав без "накладных расходов", связанных с учетом изменений для каждого пользователя посредством серии команд GRANT и REVOKE. Кроме того, нет возможности выдавать пользователю набор прав сразу на несколько таблиц в одной команде.
 

Что такое роли (SQL Roles)?

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

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

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

Примечание. Стандарт SQL определяет роль как "альтернативный" идентификатор пользователя. При этом пользователь может идентифицироваться либо через username, либо через имя роли. InterBase не предоставляет такой возможности, т.е. роль должна быть указана явно, вместе с именем пользователя. причем роль указана может быть только одна в один момент. Изменять имя роли на ходу нельзя точно так же, как и username. Помните, что роли не заменяют понятия "группы" пользователей.

Идентификация ролей

Повторимся, роль – это своего рода шаблон или набор привилегий. Сначала роль создается, затем ей назначаются привилегии относительно объектов базы данных. После этого, пользователю выдается право на использование данной роли при подключении к базе данных. Когда пользователь подключается с указанием роли, он получает все привилегии, назначенные последней. 

Аддитивность ролей

Как уже говорилось, роли являются расширением SQL. Привилегии, получаемые при использовании роли, добавляются к тем, что были выданы непосредственно пользователю. Например, предположим, что роли TEST_ADMIN назначена привилегия INSERT для таблицы TEST_SCORES. Пользователю USERA выдали привилегию SELECT для таблицы TEST_SCORES и право использовать роль TEST_ADMIN. Если при подключении USERA укажет роль TEST_ADMIN, то он будет иметь обе привилегии для таблицы TEST_SCORES: INSERT и SELECT. 

Какие экземпляры InterBase поддерживают роли?

Роли доступны в InterBase 5.0 и выше. При переходе с предыдущих версий (4.x) недостаточно просто перенести базу данных на новый сервер, необходимо пройти процедуру backup/restore под новым сервером.

Далее перечислены основные требования и условия применения ролей:

• Роль связана с базой данных, в которой она создается.
• Имя роли должно быть уникальным с учетом имен других ролей и имен пользователей.
• Роли должны указываться при подключении. Пользователь не может сменить роль, без переподключения к базе данных.
• Для того, чтобы использовать роли, база данных от IB 4.x должна быть восстановлена из резервной копии (backup) на сервере InterBase версии 5.0 или выше. Возможно использование баз данных, созданных сервером версии 4.0, на сервере версии 5.0, при этом роли не будут доступны.

Преимущества ролей

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

Модель безопасности SQL

Давайте пересмотрим пример с настройкой прав доступа для 100 таблиц 100 пользователям. Мы уже пришли к выводу, что стандартными средствами SQL для полной настройки привилегий 100 пользователям относительно 100 таблиц придется выполнить 10000 команд. При использовании ролей, в лучшем случае – все пользователи получают одинаковые права для всех таблиц, потребуется только 200 команд.

В данном случае, администратор может настроить одну роль, для этого потребуется 100 команд, для назначения роли пользователям потребуется еще 100 команд, итого 200. В общем случае, потребуется 100*n + 100 команд, где n – количество необходимых различных ролей. Например, для 5 ролей необходимо выполнить 600 команд. Т.е. понятно, что использование ролей значительно упрощает процесс настройки безопасности базы данных. 

Преимущества ролей при управлении пользователями

Также роли упрощают администрирование пользователями в существующей базе данных. Учитывая, что роли расширяют стандартный механизм разграничения доступа, нет необходимости изменять существующую схему разграничения доступа в базе данных для использования механизма ролей. Роли позволяют администратору использовать ранее определенные привилегии и одновременно определять новые привилегии. Существует несколько ключевых областей, в которых роли действительно упрощают работу администратора при управлении безопасностью в существующей базе данных. Во-первых, роли позволяют легко добавлять привилегии для нового пользователя. Во-вторых, роли реализуют управление безопасностью на групповом уровне, что, в свою очередь, делает управляемой задачу изменения привилегий для большого числа пользователей.

Для каждого нового пользователя базы данных, при использовании обычных средств SQL, администратору необходимо заново назначать права для каждой таблицы. Роли могут выступать в качестве шаблонов при назначении привилегий для новых пользователей. Т. е. можно определить роль с обобщенным набором привилегий и при добавлении нового пользователя просто назначить ему эту роль. Одним из общих решений, применяемым администраторами для выхода из ситуации с отсутствием группового управления привилегиями, является использование одной общей учетной записи для всех пользователей базы данных.
 

KDV: бывает и еще хуже – права не разграничивают, и все пользователи логинятся как SYSDBA. В результате невозможно нормально сделать базе shutdown, т. к. SYSDBA может работать в таком режиме (и перевод в shutdown ничего не меняет).

Такой подход упрощает настройку и поддержание привилегий. Основной минус, учитывая, что при подключении все пользователи указывают одно и то же имя – отсутствие возможности как-то различать их на уровне СУБД. Использование ролей в качестве шаблонов позволяет устранить этот недостаток. Администратор, по-прежнему, единовременно настраивает привилегии, на этот раз для роли, а не общего пользователя. При подключении пользователи, как и в случае с одним общим именем, указывают свои регистрационные имена, на этот раз уникальные, и, дополнительно, используемую роль, что позволяет InterBase, поддерживая механизм привилегий, дифференцировать пользователей. Между использованием общего пользователя и роли имеется два различия. Во-первых, пользователь должен указывать роль при подключении. Во-вторых, администратору необходимо всем пользователям выдать право на использование этой роли.

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

KDV: роли не являются группами в том смысле, что нельзя роли дать права другой роли (включить в роль). Так сделано для того, чтобы исключить возможность зацикливания (роль A включена в роль Б, роль Б включена в роль А и т.п.) и упростить механизм проверки прав при загрузке объектов в память сервера. Также пользователь не может одновременно получить права более чем одной роли (которая указывается при коннекте).

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

create table test_scores (i1 integer);
create role FULL_ACCESS;
grant all on test_scores to full_access;

Пользователям TEST и TEST2 выдано право на использование роли

grant FULL_ACCESS to TEST;
grant FULL_ACCESS to TEST2;

Теперь, если пользователи TEST и TEST2 при подключении укажут роль FULL_ACCESS, то они будут иметь привилегию ALL для таблицы TEST_SCORES. Если же пользователи TEST или TEST2 попробуют подключиться без указания роли FULL_ACCESS, то они не будут иметь каких-либо прав доступа к таблице TEST_SCORES:

connect \temp\employee.gdb user test password test;
  Database: \temp\employee.gdb, User: test
select * from test_scores;
  Statement failed, SQLCODE = -551
  no permission for read/select access to table TEST_SCORES
connect \temp\employee.gdb user test password test role full_access;
  Database: \temp\employee.gdb, User: test, Role: full_access
select * from test_scores;

Для того, чтобы администратору изменить права пользователей TEST и TEST2, требуется всего лишь изменить роль FULL_ACCESS. В этом примере для роли отменяется привилегия INSERT. TEST и TEST2 могут воспользоваться ролью и получить привилегии UPDATE, DELETE, SELECT, и REFERENCES для таблицы TEST_SCORES:

revoke insert on test_scores from full_access;
connect \temp\employee.gdb user test password test role full_access;
  Database: \temp\employee.gdb, User: test, Role: full_access
select * from test_scores;
insert into test_scores values (96);
  Statement failed, SQLCODE = -551
  no permission for insert/write access to table TEST_SCORES

Select, хоть и не вернул строк, выполнился успешно. Insert же вернул сообщение с ошибкой доступа. Хотя этот пример и демонстрирует группу всего лишь из двух пользователей, аналогичных результатов можно легко добиться при объединении сотен пользователей.

Гибкость ролей

Роли, кроме всего прочего, добавляют столь необходимую гибкость к стандартной модели безопасности SQL. Повторяя сказанное ранее, в SQL отсутствует возможность гибкого изменения пользовательских прав без "накладных расходов", связанных с учетом изменений для каждого пользователя посредством серии команд GRANT и REVOKE. Используя роли можно менять привилегии пользователю, указывая разные роли при подключении к базе данных, что позволяет, соблюдая безопасноть базы данных, подстраиваться под изменяющиеся потребности пользователя. Возвращаясь к примеру с жизненным циклом продукта, продемонстрируем предоставляемую механизмом ролей необходимую в данном случае гибкость. Для каждой используемой программистом роли существует определенный набор привилегий. При использовании маркетинговой роли программист не должен иметь привилегий, доступных разработчику. Так же, как и в роли разработчика, он не должен обладать правами, назначенными роли тестера. Т. е. смысл в том, что каждая роль, имеет свой собственный предопределенный набор привилегий, и программист при использовании роли получает только тот набор прав, который назначен данной роли. Переходя от образного примера непосредственно к базам данных, нужно определить три роли: MARKETING, DEVELOPMENT и QA. Каждая из ролей обладает своим набором привилегий по доступу к таблицам базы. Когда при подключении пользователь указывает одну из ролей, он получает только привилегии, выданные этой роли.
 

KDV: не следует перебарщивать с раздачей прав, осуществляя это для группы разработчиков из 5-10 человек. Может оказаться, что вы только зря потратите время и усложните жизнь отдельным разработчикам. Лучше потратить это время на планирование и организацию прав доступа для пользователей (приложений).

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

Суммарный привилегии = Привилегии, непосредственно выданные пользователю + Привилегии, назначенные используемой роли.

Продолжая рассматривать пример с жизненным циклом программного продукта, предположим, что пользователь BJONES получил право использовать роль QA. BJONES несёт ответственность за ежемесячный подсчет количества изменений, внесенных разработчиками в исходный код. Учитывая, что ему выдано право на использование только роли QA, он не может получить доступ к таблицам, используемым в разработке. Администратор, в свою очередь, не хотел бы назначать BJONES роль DEVELOPMENT, потому что необходимые права являются лишь подмножеством привилегий, имеющихся у роли DEVELOPMENT. В этом случае, администратор может выдать требуемый набор привилегий непосредственно пользователю. Тогда при подключении с указанием роли QA, BJONES будет обладать привилегиями как по доступу к подмножеству таблиц, используемым в разработке, так и к таблица, используемым в тестировании продукта. Исходя из "соединительной" природы ролей, BJONES получает привилегии, назначенные используемой роли, плюс привилегии, непосредственно выданные ему администратором.
 

Применение ролей

Создание роли

Для того, чтобы создать роль, необходимо воспользоваться оператором CREATE ROLE. По умолчанию, после создания роль не обладает какими-либо привилегиями. Соответственно, все необходимые права по доступу к объектам базы данных должны быть назначены до использования роли. Учитывая, что создания роли как таковой не прибавляет каких-либо прав, любой пользователь может создать роль. Также, исходя из того, что роль определяется и храниться непосредственно в базе данных, необходимо подключиться к этой базе до создания роли. Приведем пример создания роли:

CREATE ROLE FULL_ACCESS;

KDV: одним из "хакерских" способов защиты БД от доступа SYSDBA (при распространении приложений с базами данных) является создание роли SYSDBA, после чего пользователь SYSDBA к базе логиниться не может. Однако, нельзя гарантировать что такое поведение останется во всех будущих версиях InterBase и его клонах. Например, в Firebird 1.5 RC5 для создания роли SYSDBA база должна быть создана не от имени SYSDBA, а также не должна иметь объектов, созданных SYSDBA.

Предоставление привилегий роли

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

GRANT ON [TABLE] {tablename | viewname} TO rolename;

Для того, чтобы иметь возможность назначить привилегию роли, необходимо быть:

• SYSDBA
• Владельцем таблицы или представления
• Пользователем, имеющим право назначать привилегии для этой таблицы или представления (т. е. иметь GRANT OPTION)

Приведем примеры, предоставления объектных прав роли:

GRANT ALL ON TEST_SCORES TO FULL_ACCESS;
GRANT INSERT, SELECT ON TABLE EMPLOYEE TO BJONES;

Назначение роли пользователю

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

Оператор предоставления пользователю права использования роли имеет следующий синтаксис:

GRANT {rolename [, rolename ...]} TO {PUBLIC | {[USER] username [, [USER] username ...]} }
[WITH ADMIN OPTION];

Предложение WITH ADMIN OPTION позволяет пользователю, в свою очередь, назначать эту роль другим пользователям. Например, если пользователю USERA назначили роль DEVELOPER с предложением WITH ADMIN OPTION, то он может назначить эту роль другим пользователям. В следующем примере создается роль FULL_ACCESS, ей выдается привилегия ALL для таблицы TEST_SCORES, а затем роль назначается пользователю BJONES.

CREATE ROLE FULL_ACCESS;
GRANT ALL ON TEST_SCORES TO FULL_ACCESS;
GRANT FULL_ACCESS TO BJONES;

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

connect \temp\employee.gdb user bjones password bjones;
  Database: \temp\employee.gdb, User: bjones
select * from test_scores;
  Statement failed, SQLCODE = -551
  no permission for read/select access to table TEST_SCORES
 

Теперь BJONES указывает роль при подключении. Пользователь может выполнить выборку из таблицы, т. к. роли FULL_ACCESS была выдана привилегия ALL для таблицы TEST_SCORES.

connect \temp\employee.gdb user bjones password bjones role full_access;
  Database: \temp\employee.gdb, User: bjones, Role: full_access
select * from test_scores;

Использование роли

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

Распространенная ошибка: Часто встречается неправильное представление о механизме ролей, что после того как пользователю назначили роль, он сразу же получает все привилегии, выданные этой роли. Это неверно. Чтобы пользователь приобрел все привилегии, назначенные роли, он должен указать эту роль при подключении к базе данных. Если же пользователь при подключении не указал имя роли, то ему не будут доступны ни одна из привилегий этой роли.

Ниже приведен пример подключения пользователя BJONES к базе данных с указанием роли FULL_ACCESS. В примере используется ISQL, утилита InterBase интерактивного выполнения команд SQL:

SQL> connect \temp\employee.gdb user bjones password bjones role full_access;
Database: \temp\employee.gdb, User: bjones, Role: full_access

Следующий пример демонстрирует аналогичное подключение, но с использованием DSQL.

File: sampleapi.c
#include
#include
#include "ibase.h"
int main()
{
ISC_STATUS isc_status[20];
isc_db_handle db_handle;
char *dpb;
short dpb_length;
int i;
/* clear database handle */
db_handle = 0L;
/* add dpb version to dpb */
dpb = (char *)0;
dpb_length = 0;
/* add user, password, and role to dpb */
isc_expand_dpb(&dpb, &dpb_length,
  isc_dpb_user_name, "bjones",
  isc_dpb_password, "bjones",
  isc_dpb_sql_role_name, "full_access",
  NULL);
/* attach to database */
isc_attach_database(isc_status, 0, "testdb.gdb", &db_handle,
  dpb_length, dpb);
}

KDV: по использованию ролей в BDE см. архивLINK и FAQ.

Отмена привилегий роли

Используя команду REVOKE, можно отменить привилегии для ролей, которым до этого были назначены соответствующие привилегии. Если какая-то привилегия отнимается у роли, то все пользователи, использующие эту роль, теряют право на выполнение соответствующих команд. Синтаксис команды REVOKE в данном случае следующий:

REVOKE ON [TABLE] tablename FROM rolename;

Пример отмены привилегии INSERT для таблицы TEST_SCORES у роли FULL_ACCESS:

REVOKE INSERT ON TEST_SCORES FROM FULL_ACCESS;

Отмена ролей пользователя

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

REVOKE FROM username;

В примере пользователю BJONES отменяется право на использование роли FULL_ACCESS. После чего BJONES больше не сможет подключиться с указанием этой роли.

REVOKE FULL_ACCESS FROM BJONES;

Удаление роли

Когда роль перестает быть нужной, её можно удалить из базы данных. Удалить роль имеет право SYSDBA или пользователь, создававший роль. При удалении роли, все привилегии, назначенные ей, также удаляются из базы данных. Для удаления роли используется следующий синтаксис:

DROP ROLE rolename;

Пример демонстрирует удаление роли FULL_ACCESS:

DROP ROLE FULL_ACCESS;

Где и как поддерживаются роли?

Для успешного использования ролей, необходимо наличие возможности в прикладных инструментах при подключении к базе данных определять имя роли. Для этого, во-первых, сам InterBase должен предложить интерфейс, позволяющий передавать имя роли при соединении с базой данных, во-вторых, средства разработки должны реализовать поддержку предложенных способов. Таким образом, для конечного пользователя поддержка ролей представляется двух этапным процессом.

Интерфейсы, предоставляемые InterBase

KDV: раздел целиком удален за ненадобностью. Все, что было изложено в этом разделе, вы уже прочитали выше с той же степенью подробностей.

Роли делают безопасность управляемой

Подводя итоги, безопасность базы данных – это существенно необходимая вещь. Стандартная модель безопасности SQL вполне адекватна и пригодна для обеспечения защиты ваших данных. Роли базируются на стандартной модели и добавляют эффективность в управление безопасностью, обеспечивая разграничение доступа на уровне групп, отсутствующее в стандарте SQL. Использование ролей делает вашу жизнь проще.
 

Прим. перев. 1. InterBase позволяет выдавать привилегии несуществующим в БД ролям; баг #anchor_223128 [4]
2. Для избежания проблем с привилегиями, в версиях вплоть до FB1.5 RC4 (включая IBv6 и ниже, соответственно) не рекомендуется давать объектам имена длиннее 27 символов. В связи с обрезанием символов, очередная выданная привилегия перепишет собой в системных таблицах результат предыдущей команды GRANT для объектов, чьи имена различаются последними 4 байтами; баг #anchor_222375 [4].
3. Revoke является case-sensitive; баг #anchor_229231. Исправлено в FB 0.9-5.
4. Проблема с проверкой прав ролей для view; баг #anchor_442140.
5. Несоответствие привилегии REFERENCES стандарту; баг #anchor_458888. Исправлено в FB 1.0
6. Update с where выдает ошибку отсутствия прав доступа, если дан grant update но не дан grant select; баг #555868.

Дополнительная литература

1. InterBase 6. Operations Guide
2. InterBase 6. Data Definition Guide
3. Ivan Prenosil's Article "Security – Enhanced isc4.gdb"
4. Firebird's Bug Database (http://firebird.sourceforge.net/)
5. Раздел "Разграничение доступа к записям" в статье "Древовидные структуры, ч. 2"LINK

Перевод впервые опубликован на www.ibase.ru 25.08.2003. Копирование только с разрешения support@ibase.ru.