Безопасность всей базы данных зависит от проверки подлинности идентификатора пользователя.
Подлинность пользователя может выполняться несколькими способами в зависимости от установок параметра AuthServer
в файле конфигурации firebird.conf.
Этот параметр содержит список доступных плагинов проверки подлинности.
Если проверить подлинность с помощью первого плагина не удалось, то сервер переходит к следующему плагину и т.д.
Если ни один плагин не подтвердил подлинность, то пользователь получает сообщение об ошибке.
Информация о пользователях, зарегистрированных для конкретного сервера Firebird, хранится в особой базе данных безопасности (security database) — {secdb}.
Для каждой БД база данных безопасности может переопределена в файле databases.conf (параметр SecurityDatabase).
Любая база данных может быть базой данных безопасности для самой себя.
Имя пользователя может состоять максимум из 63 символов.
Максимальная длина пароля зависит от плагина проверки подлинности и плагина управления пользователями (параметр UserManager), регистр — учитывается.
По умолчанию будет выбран первый плагин из списка плагинов управления пользователями.
Этот плагин можно изменить в SQL командах управления пользователями.
Для плагина SRP эффективная длина пароля ограничена 20 байтами *. Для плагина Legacy_UserManager максимальная длина пароля равна 8 байт.
|
Note
|
*Почему эффективная длина пароля ограничена 20 символами?
На длину пароля нет ограничения в 20 байт и он может быть использован. Хеши различных паролей, длина которых более 20 байт, тоже различны. Предел эффективности наступает из-за ограниченной длины хеша в SHA1 равном 20 байт или 160 бит. Рано или поздно найдётся более короткий пароль с тем же хешем с помощью атаки Brute Force. Именно поэтому часто говорят, что эффективная длина пароля для алгоритма SHA1 составляет 20 байт. |
Встроенная версия сервера (embedded), не использует аутентификацию. Тем не менее имя пользователя, и если необходимо роль, должны быть указаны в параметрах подключения, поскольку они используются для контроля доступа к объектам базы данных.
Пользователь SYSDBA или пользователь вошедший с ролью RDB$ADMIN, получают неограниченный доступ к базе данных.
Если пользователь является владельцем базы данных, то без указания роли RDB$ADMIN он получает неограниченный доступ ко всем объектам принадлежащим этой базе данных.
В Firebird существует специальная учётная запись SYSDBA, которая существует вне всех ограничений безопасности и имеет полный доступ ко всем базам данных сервера.
В POSIX системах, включая MacOSX, имя пользователя POSIX будет интерпретировано как имя пользователя Firebird Embedded, если имя пользователя не указано явно.
В POSIX системах, кроме MacOSX, пользователь SYSDBA не имеет пароля по умолчанию.
Если полная установка осуществляется с помощью стандартных скриптов, то одноразовый пароль будет создан и сохранён в текстовом файле в том же каталоге, что и {secdb}, обычно это /opt/firebird/.
Файл с паролем имеет имя SYSDBA.password.
|
Note
|
При выполнении установки с помощью определённого распространяемого установщика, расположение файла базы данных безопасности и файла с паролем может отличаться от стандартного. |
В операционных системах семейства Windows NT вы также можете пользоваться учётными записями ОС.
Для этого необходимо, чтобы в файле конфигурации firebird.conf (параметр AuthServer) в списке плагинов присутствовал провайдер Win_Sspi.
Кроме того, этот плагин должен присутствовать и в списке плагинов клиентской стороны (параметр AuthClient).
Администраторы операционной системы Windows автоматически не получают права SYSDBA при подключении к базе данных (если, конечно, разрешена доверенная авторизация). Имеют ли администраторы автоматические права SYSDBA, зависит от установки значения флага AUTO ADMIN MAPPING.
|
Note
|
До Firebird 3.0 при включенной доверительной аутентификации, пользователи прошедшие проверку по умолчанию автоматически отображались в |
Владелец базы данных — это либо текущий пользователь (CURRENT_USER), который был момент создания, либо пользователь который был указан в параметрах USER в операторе CREATE DATABASE.
Владелец базы данных является администратором в ней и имеет полный доступ ко всем объектам этой базы данных, даже созданных другими пользователями.
Системная роль RDB$ADMIN, присутствует в каждой базе данных.
Предоставление пользователю роли RDB$ADMIN в базе данных даёт ему права SYSDBA, но только в текущей базе данных.
Привилегии вступают в силу сразу после входа в обычную базу данных с указанием роли RDB$ADMIN, после чего пользователь получает полный контроль над всеми объектами базы данных.
Роль RDB$ADMIN может быть предоставлена с использованием ключевого слова DEFAULT.
В этом случае пользователь автоматически будет получать административные привилегии даже если он не указал роль RDB$ADMIN при входе.
Предоставление в базе данных безопасности даёт возможность создавать, изменять и удалять учётные записи пользователей.
В обоих случаях пользователь с правами RDB$ADMIN роли может всегда передавать эту роль другим.
Другими словами, “WITH ADMIN OPTION” уже встроен в эту роль и эту опцию можно не указывать.
Для предоставления и удаления роли RDB$ADMIN в обычной базе данных используются операторы GRANT и REVOKE, как и для назначения и отмены остальных ролей.
GRANT [DEFAULT] [ROLE] RDB$ADMIN TO username REVOKE [DEFAULT] [ROLE] RDB$ADMIN FROM username
RDB$ADMIN| Параметр | Описание |
|---|---|
username |
Имя пользователя, которому назначается или отбирается роль |
Если в операторе GRANT присутствует ключевое слово DEFAULT, то пользователь автоматически будет получать административные привилегии даже если он не указал роль RDB$ADMIN при входе.
Привилегии на роль RDB$ADMIN могут давать только администраторы.
Для использования прав роли RDB$ADMIN пользователь просто указывает её при соединении с базой данных, или же роль RDB$ADMIN выдали пользователю с использованием ключевого слова DEFAULT.
Он также может указать её позднее с помощью оператора SET ROLE.
Так как никто не может соединиться с базой данных пользователей, то операторы GRANT и REVOKE здесь не могут использоваться. Вместо этого роль RDB$ADMIN предоставляют и удаляют SQL командами управления пользователями: CREATE USER и ALTER USER, в которых указываются специальные опции GRANT ADMIN ROLE и REVOKE ADMIN ROLE.
CREATE USER newuser PASSWORD 'password' ... GRANT ADMIN ROLE ... ALTER USER existinguser GRANT ADMIN ROLE ALTER USER existinguser REVOKE ADMIN ROLE
RDB$ADMIN| Параметр | Описание |
|---|---|
newuser |
Имя вновь создаваемого пользователя. Максимальная длина 63 символа. |
existinguser |
Имя существующего пользователя. |
password |
Пароль пользователя. Чувствительно к регистру. |
|
Important
|
Пожалуйста, помните, что |
Привилегии на роль RDB$ADMIN могут давать только администраторы.
То же самое можно сделать используя утилиту gsec указав параметр -admin для сохранения атрибута RDB$ADMIN учётной записи пользователя:
gsec -add new_user -pw password -admin yes gsec -mo existing_user -admin yes gsec -mo existing_user -admin no
|
Note
|
В зависимости от административного статуса текущего пользователя для утилиты |
Для управления учётными записями пользователей через SQL пользователь, имеющий права на роль RDB$ADMIN, должен подключиться к базе данных с этой ролью.
Так как к базе данных пользователей не имеет права соединяться никто, то пользователь должен подключиться к обычной базе данных, где он также имеет права на роль RDB$ADMIN.
Он определяет роль при соединении с обычной базой данных и может в ней выполнить любой SQL запрос.
Это не самое элегантное решение, но это единственный способ управлять пользователями через SQL запросы.
Если нет обычной базы данных, где у пользователя есть права на роль RDB$ADMIN, то управление учётными записями посредством SQL запросов недоступно.
Для управления пользователями через утилиту gsec роль RDB$ADMIN должна быть указана в переключателе -role.
только Windows.
Администраторы операционной системы Windows автоматически не получают права SYSDBA при подключении к базе данных (если, конечно, разрешена доверенная авторизация). Имеют ли администраторы автоматические права SYSDBA зависит от установки значения флага AUTO ADMIN MAPPING.
Это флаг в каждой из баз данных, который по умолчанию выключен.
Если флаг AUTO ADMIN MAPPING включен, то он действует, когда администратор Windows:
-
подключается с помощью доверенной аутентификации
-
не определяет никакой роли при подключении.
После успешного “auto admin” подключения текущей ролью будет являться RDB$ADMIN.
Включение и выключение флага AUTO ADMIN MAPPING в обычной базе данных осуществляется следующим образом:
ALTER ROLE RDB$ADMIN SET AUTO ADMIN MAPPING -- включение
ALTER ROLE RDB$ADMIN DROP AUTO ADMIN MAPPING -- выключениеЭти операторы могут быть выполнены пользователями с достаточными правами, а именно:
-
владелец базы данных;
|
Note
|
Оператор ALTER ROLE RDB$ADMIN SET AUTO ADMIN MAPPINGявляется упрощённым видом оператора создания отображения предопределённой группы CREATE MAPPING WIN_ADMINS
USING PLUGIN WIN_SSPI
FROM Predefined_Group
DOMAIN_ANY_RID_ADMINS
TO ROLE RDB$ADMIN;Соответственно оператор ALTER ROLE RDB$ADMIN DROP AUTO ADMIN MAPPINGэквивалентен оператору DROP MAPPING WIN_ADMINS;Подробней см. Отображение объектов безопасности. |
В обычных базах данных статус AUTO ADMIN MAPPING проверяется только во время подключения.
Если Администратор имеет роль RDB$ADMIN потому, что произошло автоматическое отображение во время входа, то он будет удерживать эту роль на протяжении всей сессии, даже если он или кто-то другой в это же время выключает автоматическое отображение.
Точно также, включение AUTO ADMIN MAPPING не изменит текущую роль в RDB$ADMIN для Администраторов, которые уже подключились.
Оператором ALTER ROLE RDB$ADMIN невозможно включить или выключить флаг AUTO ADMIN MAPPING в базе данных пользователей.
Однако вы можете создать глобальное отображение предопределённой группы DOMAIN_ANY_RID_ADMINS на роль RDB$ADMIN следующим образом:
CREATE GLOBAL MAPPING WIN_ADMINS
USING PLUGIN WIN_SSPI
FROM Predefined_Group
DOMAIN_ANY_RID_ADMINS
TO ROLE RDB$ADMIN;Кроме того для включения AUTO ADMIN MAPPING в базе данных пользователей можно использовать утилиту командной строки gsec:
gsec -mapping set gsec -mapping drop
|
Note
|
В зависимости от административного статуса текущего пользователя для утилиты |
Только SYSDBA может включить AUTO ADMIN MAPPING, если он выключен, но любой администратор может выключить его.
При выключении AUTO ADMIN MAPPING пользователь отключает сам механизм, который предоставлял ему доступ и, таким образом, он не сможет обратно включить AUTO ADMIN MAPPING.
Даже в интерактивном gsec сеансе новая установка флага сразу вступает в силу.
Администратор — это пользователь, которые имеет достаточные права для чтения и записи, создания, изменения и удаления любого объекта в базе данных. В таблице показано, как привилегии “Суперпользователя” включены в различных контекстах безопасности Firebird.
| Пользователь | Роль RDB$ADMIN |
Замечание |
|---|---|---|
SYSDBA |
Автоматически |
Существует автоматически на уровне сервера. Имеет полные привилегии ко всем объектам во всех базах данных. Может создавать, изменять и удалять пользователей, но не имеет прямого доступа к базе данных безопасности. |
Пользователь root в POSIX |
Автоматически |
Так же как |
Суперпользователь в POSIX |
Автоматически |
Так же как |
Владелец базы данных |
Автоматически |
Так же как |
Администраторы Windows |
Устанавливается в |
Так же как
|
Обычный пользователь |
Должна быть предварительно выдана и должна быть указана при входе |
Так же как |
Пользователь POSIX |
Должна быть предварительно выдана и должна быть указана при входе |
Та кже как |
Пользователь Windows |
Должна быть предварительно выдана и должна быть указана при входе |
Так же как |