The RDB$ADMIN role

Table of Contents

In normal databases
In the security database

Added in: 2.5

Description: Firebird 2.5 introduces the RDB$ADMIN system role, which is predefined in every database. Granting someone the RDB$ADMIN role in a database gives him or her SYSDBA rights in that database only. In a normal database, this means full control over all objects. In the security database, it means the ability to create, alter and drop user accounts. In both cases, the grantee can always pass the role on to others. In other words, “WITH ADMIN OPTION” is built in and need not be specified.

In normal databases

Table of Contents

Granting the RDB$ADMIN role in a normal database
Using the RDB$ADMIN role in a normal database

Granting the RDB$ADMIN role in a normal database

In a regular database, the RDB$ADMIN role can be granted and revoked with the usual syntax:

GRANT RDB$ADMIN TO username
REVOKE RDB$ADMIN FROM username

Grantors can be:

The database owner;
SYSDBA;
anybody who has the RDB$ADMIN role in the database and specified it while connecting;
if AUTO ADMIN MAPPING is on for the database: any Windows administrator who connected to the database using trusted authentication without specifying a role.

Using the RDB$ADMIN role in a normal database

To make use of his RDB$ADMIN privileges, the grantee simply specifies the role when connecting to the database.

In the security database

Table of Contents

Granting the RDB$ADMIN role in the security database
Using the RDB$ADMIN role in the security database

Granting the RDB$ADMIN role in the security database

Since nobody can connect to the security database, the GRANT and REVOKE statements cannot be used here. Instead, the RDB$ADMIN role is granted and revoked with the new SQL user management commands:

CREATE USER newuser PASSWORD 'password' GRANT ADMIN ROLE
ALTER USER existinguser GRANT ADMIN ROLE
ALTER USER existinguser REVOKE ADMIN ROLE

Please notice that GRANT ADMIN ROLE and REVOKE ADMIN ROLE are not GRANT and REVOKE statements. They are three-word parameters to CREATE and ALTER USER.

Alternatively, gsec can be used with the -admin parameter:

gsec -add newuser -pw password -admin yes
gsec -mo existinguser -admin yes
gsec -mo existinguser -admin no

Depending on the situation, more parameters may be needed when invoking gsec, e.g. -user and -pass, or -trusted.

Grantors can be:

SYSDBA;
anybody who has the RDB$ADMIN role in the security database and specified it while connecting (or while invoking gsec);
if AUTO ADMIN MAPPING is on for the security database: any Windows administrator who connected (or invoked gsec) using trusted authentication without specifying a role.

Using the RDB$ADMIN role in the security database

To manage user accounts through SQL, the grantee must specify the RDB$ADMIN role when connecting. But this poses a problem, because nobody can connect to the security database. The solution is that the user connects to another – regular – database where he also has RDB$ADMIN rights. He specifies the role when connecting to the regular database, and can then give any SQL user management command. It's not the most elegant of solutions, but it is the only way. If there isn't a regular database where the grantee has the RDB$ADMIN role, the SQL route is blocked.

To perform user management with gsec, the grantee must provide the extra parameter -role rdb$admin.