The elevated privileges take effect when the user is logged in to that regular database under the RDB$ADMIN role and give full control over all objects in the database.

    Being granted the RDB$ADMIN role in the security database confers the authority to create, edit and delete 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.

    Granting the RDB$ADMIN Role in the Security Database

    Since nobody — not even SYSDBA — can connect to the security database, the GRANT and REVOKE statements are of no use for this task. Instead, the RDB$ADMIN role is granted and revoked using the SQL statements for user management:

    The grantor must be already logged in as an administrator.

    , ALTER USER

    Doing the Same Task Using gsec

    An alternative is to use gsec with the -admin parameter to store the RDB$ADMIN attribute on the user’s record:

    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. No user can connect to the security database, so the solution is that the user connects to a regular database where he also has RDB$ADMIN rights, supplying the RDB$ADMIN role in his login parameters. From there, he can submit any SQL user management command.

    The SQL route for the user is blocked for any database in which he has not been the granted the RDB$ADMIN role.

    Using gsec with RDB$ADMIN Rights

    To perform user management with gsec, the user must provide the extra switch .

    Granting the RDB$ADMIN Role in a Regular Database

    In a regular database, the RDB$ADMIN role is granted and revoked with the usual syntax for granting and revoking roles:

    In order to grant and revoke the RDB$ADMIN role, the grantor must be logged in as an administrator.

    See also

    , REVOKE

    Using the RDB$ADMIN Role in a Regular Database

    To exercise his RDB$ADMIN privileges, the grantee simply includes the role in the connection attributes when connecting to the database.

    AUTO ADMIN MAPPING

    If AUTO ADMIN MAPPING is enabled in the database, it will take effect whenever a Windows Administrator connects:

    1. using trusted authentication, and

    2. without specifying any role

    After a successful “auto admin” connection, the current role is set to RDB$ADMIN.

    Auto Admin Mapping in Regular Databases

    To enable and disable automatic mapping in a regular database:

    Either statement must be issued by a user with sufficient rights, that is:

    • the database owner

    In regular databases, the status of AUTO ADMIN MAPPING is checked only at connection time. If an Administrator has the RDB$ADMIN role because auto-mapping was on when he logged in, he will keep that role for the duration of the session, even if he or someone else turns off the mapping in the meantime.

    Likewise, switching on AUTO ADMIN MAPPING will not change the current role to RDB$ADMIN for Administrators who were already connected.

    Auto Admin Mapping in the Security Database

    No SQL statements exist to switch automatic mapping on and off in the security database. Instead, gsec must be used:

    More gsec switches may be needed, depending on what kind of log-in you used to connect, e.g., -user and -pass, or -trusted.