<< GRANT and REVOKE | FB 2.5 Language Reference | AUTO ADMIN MAPPING >>

The The RDB$ADMIN role

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

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.

back to top of page

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.

back to top of page
<< GRANT and REVOKE | FB 2.5 Language Reference | AUTO ADMIN MAPPING >>