5.1.4. Appointing co-administrators

Note: What follows here is not essential knowledge for beginners. You can skip it if you like and go on to the Security section.

In Firebird 2.5 and up, SYSDBA (and others with administrator rights) can appoint co-administrators. This is done with the GRANT ADMIN ROLE directive:

  1. create user bigbill password 'bigsekrit7foryou' grant admin role;
  2. alter user littlejohn grant admin role;

The first command creates user bigbill as a Firebird administrator, who can add, alter and drop users. The second command grants administrator privileges to the existing user littlejohn.

To revoke administrator privileges from an account, use ALTER USER …​ REVOKE ADMIN ROLE.

Notes

  • GRANT ADMIN ROLE and REVOKE ADMIN ROLE are not GRANT and REVOKE statements, although they look that way. They are parameters to the CREATE and ALTER USER statements. The actual role name involved here is RDB$ADMIN. This role also exists in regular databases; more about that in a minute.

  • Every user who has received administrator rights can pass them on to others. Therefore, there is no explicit WITH ADMIN OPTION.

  • Just for completeness, administrators can also grant admin rights to an existing user by connecting to the security database and issuing a regular GRANT statement:

    1. grant rdb$admin to littlejohn

Differences between co-administrators and SYSDBA

  • Co-admins can create, alter and drop users, but they have no automatic privileges in regular databases, like SYSDBA has.

  • Unlike SYSDBA, co-admins must specify the RDB$ADMIN role explicitly if they want to exert their rights as system administrator:

    1. connect security.db user bigbill password bigsekrit7foryou role rdb$admin

    For reasons explained elsewhere in this guide, connecting to the security database like this may fail if a Superserver is running. On Windows, you may circumvent this by prepending xnet:// to the database path or alias, but on Posix, you’re stuck. The only solution there is to grant the co-admin the RDB$ADMIN role in at least one regular database as well. (A database that uses the security database in question, of course.) This is done in the usual way that roles are granted:

    1. grant rdb$admin to bigbill

    Grantors can be the database owner, SYSDBA, and every other user who has the RDB$ADMIN role in that database and has specified it while connecting. Every RDB$ADMIN member in a database can pass the role on to others, so again there is no WITH ADMIN OPTION. Once the co-admin has obtained the role, he can connect to the (regular) database with it and use the SQL user management commands. It’s not the most elegant of solutions, but it works.

    Please remember:

    The RDB$ADMIN role in a database gives the grantee SYSDBA rights in that database only!

    • If it is the security database, the grantee can manage user accounts, but has no special privileges in other databases.

    • If it is a regular database, the grantee can control that database like he was SYSDBA, but again has no special privileges in other databases, and has no user administration privileges.

    Of course it is possible to grant a user the RDB$ADMIN role in several databases, including the security database.