New RDB$ADMIN System Role
Alex Peshkov
A new pre-defined system role RDB$ADMIN has been added for transferring SYSDBA privileges to another user. Any user, when granted the role in a particular database, acquires SYSDBA-like rights when attaching to that database with the RDB$ADMIN role specified.
To assign it, SYSDBA should log in to that database and grant this role to the user, in the same way he would grant any other role to a user.
The following example transfers SYSDBA privileges to users named User1 and Admins\ADMINS. The second user in our example is typical for Windows trusted authentication:
GRANT RDB$ADMIN TO User1;
GRANT RDB$ADMIN TO "Admins\ADMINS";
Note
For Windows trusted authentication, a database can be set up to provide the RDB$ADMIN role to Windows Administrators automatically. This is described in more detail presently.
Windows Domain Administrators
On POSIX hosts, the root user always had SYSDBA privileges, but the same was not possible for a domain administrator on Windows until Firebird 2.1. There, a configuration parameter, Authentication, was introduced whereby a user logged in as a Windows domain administrator could automatically gain server
access with SYSDBA privileges through trusted user authentication. The mechanism for achieving that has changed with the introduction of the new system role and associated behaviour in v.2.5.
Automatically Mapping RDB$ADMIN to a Windows User
The situation has not changed for the root user on POSIX but, on Windows, a domain administrator must now be granted the RDB$ADMIN role in order to get SYSDBA
access. By default, the SYSDBA must perform this GRANT manually for any user, including a domain administrator. However, the SYSDBA can configure it to happen automatically for Windows Administrators if the Authentication parameter in firebird.conf is 'mixed' or 'trusted'. A new ALTER ROLE syntax is is implemented for this specialised purpose.
Auto-mapping Syntax
To configure a database to auto-grant the RDB$ADMIN role to Administrators, use the following statement:
ALTER ROLE RDB$ADMIN
SET AUTO ADMIN MAPPING;
To revert to the default setting, preventing administrators from getting SYSDBA privileges automatically, issue this statement:
ALTER ROLE RDB$ADMIN
DROP AUTO ADMIN MAPPING;
Escalating RDB$ADMIN Scope
Because security2.fdb is created as (or should be upgraded to) an ODS 11.2 database, it has the pre-defined RDB$ADMIN role, too. SYSDBA can grant RDB$ADMIN in security2.fdb to a user if that user needs the same rights as SYSDBA to administer all other users through gsec or the Services
API, i.e., create and drop users or alter any user.
The auto-mapping facility described above is also applicable, if required.
Important
If the user attaches with a user database role passed in the DPB (connection parameters), it will not be replaced with RDB$ADMIN, i.e., he/she will not get SYSDBA rights.