The root User
The root user can act directly as SYSDBA on Firebird Embedded.Firebird will treat root as though it were SYSDBA, and it provides access to all databases on the server.
The root user can act directly as SYSDBA on Firebird Embedded.Firebird will treat root as though it were SYSDBA, and it provides access to all databases on the server.
On the Windows Server operating systems, operating system accounts can be used.Windows authentication (also known as “trusted authentication”) can be enabled by including the Win_Sspi
plugin in the AuthServer
list in firebird.conf
.The plugin must also be present in the AuthClient
setting at the client-side.
Windows operating system administrators are not automatically granted SYSDBA privileges when connecting to a database.To make that happen, the internally-created role RDB$ADMIN
must be altered by SYSDBA or the database owner, to enable it.For details, refer to the later section entitled [fblangref50-security-autoadminmapping].
Note
|
Prior to Firebird 3.0, with trusted authentication enabled, users who passed the default checks were automatically mapped to |
The “owner” of a database is either the user who was CURRENT_USER
at the time of creation (or restore) of the database or, if the USER
parameter was supplied in the CREATE DATABASE
statement, the specified user.
“Owner” is not a username.The user who is the owner of a database has full administrator privileges with respect to that database, including the right to drop it, to restore it from a backup and to enable or disable the [fblangref50-security-autoadminmapping] capability.
USER_MANAGEMENT
System PrivilegeA user with the USER_MANAGEMENT
system privilege in the security database can create, alter and drop users.To receive the USER_MANAGEMENT
privilege, the security database must have a role with that privilege:
create role MANAGE_USERS
set system privileges to USER_MANAGEMENT;
There are two options for the user to exercise these privileges:
Grant the role as a default role.The user will always be able to create, alter or drop users.
grant default MANAGE_USERS to user ALEX;
Grant the role as a normal role.The user will only be able to create, alter or drop users when the role is specified explicitly on login or using SET ROLE
.
grant MANAGE_USERS to user ALEX;
If the security database is a different database than the user connects to — which is usually the case when using {secdb}
— then a role with the same name must also exist and be granted to the user in that database for the user to be able to activate the role.The role in the other database does not need any system privileges or other privileges.
Note
|
The |
RDB$ADMIN
RoleThe internally-created role RDB$ADMIN
is present in all databases.Assigning the RDB$ADMIN
role to a regular user in a database grants that user the privileges of the SYSDBA
, in that database only.
The elevated privileges take effect when the user is logged in to that regular database under the RDB$ADMIN
role, and gives full control over all objects in that database.
Being granted the RDB$ADMIN
role in the security database confers the authority to create, alter and drop user accounts.
In both cases, the user with the elevated privileges can assign RDB$ADMIN
role to any other user.In other words, specifying WITH ADMIN OPTION
is unnecessary because it is built into the role.