FirebirdSQL logo
 SecuritySQL Statements for User Management 

Windows Hosts

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 CURRENT_USER.In Firebird 3.0 and later, the mapping must be done explicitly using CREATE MAPPING.

The Database Owner

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.

Users with the USER_MANAGEMENT System Privilege

A 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:

  1. 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;

  2. 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 USER_MANAGEMENT system privilege does not allow a user to grant or revoke the admin role.This requires the RDB$ADMIN role.