FirebirdSQL logo

Changing the SYSDBA password

One Firebird account is created automatically as part of the installation process: SYSDBA.This account has all the privileges on the server and cannot be deleted.Depending on version, OS, and architecture, the installation program will either

  • install the SYSDBA user with the password masterkey, or

  • ask you to enter a password during installation, or

  • generate a random password and store that in the file SYSDBA.password within your Firebird installation directory.

If the password is masterkey and your server is exposed to the Internet at all — or even to a local network, unless you trust every user with the SYSDBA password — you should change it immediately.Fire up isql or another Firebird client and connect to a database.In this example, the “employee” example database is used, because its alias is always present in a freshly installed Firebird setup:

connect localhost:employee user sysdba password masterkey;

If you do this in isql, it should respond with:

Database: localhost:employee, User: SYSDBA

Now alter the sysdba password:

alter user sysdba set password 'Zis4_viZuna83YoYo';
Tip

Instead of USER SYSDBA you can also use CURRENT USER, which always refers to the user you are logged in as.

If the command succeeds, you won’t get any feedback.Instead, isql will just print the next “SQL>”-prompt, thus indicating that all is well and your further input is awaited.

Please notice that unlike “regular” usernames, Firebird passwords are always case-sensitive.

Warning

Depending on the UserManager and AuthServer setting in firebird.conf or databases.conf, you may have two or more SYSDBA accounts.Make sure to change the password for all of them.

If you have enabled legacy authentication, you may want to delete the legacy SYSDBA account, as it is insecure and restricts the maximum password length to 8 characters.

Adding Firebird user accounts

Firebird allows the creation of many different user accounts.Each of them can own databases and also have various types of access to databases and database objects it doesn’t own.

Assuming you are connected to a database as SYSDBA, you can add a user account as follows:

create user billyboy password 'TooLongFor8099Comfort';

The full range of user management commands is:

CREATE USER username
  <user_option> [<user_option> ...]
  [TAGS (<user_var> [, <user_var> ...]]

[CREATE OR] ALTER {USER username | CURRENT USER}
  [SET] [<user_option> [<user_option> ...]]
  [TAGS (<user_var> [, <user_var> ...]]

DROP USER username)
  [USING PLUGIN _plugin_name]

<user_option> ::=
    PASSWORD 'password'
  | FIRSTNAME 'firstname'
  | MIDDLENAME 'middlename'
  | LASTNAME 'lastname'
  | {GRANT | REVOKE} ADMIN ROLE
  | {ACTIVE | INACTIVE}
  | USING PLUGIN plugin_name

<user_var> ::=
    tag_name = 'tag_value'
  | DROP tag_name

Tags are optional key-value pairs that can be freely defined by the user.The key (tag name) must be a valid SQL identifier, the value a non-NULL string of at most 255 bytes.

Only SYSDBA and co-admins can use all these commands.Ordinary users can change their own parameters (such as password, name parts and tags, but not active/inactive) using ALTER USER name or ALTER CURRENT USER.It is not possible to change an account name.

Examples:

create user dubya password 'Xwha007_noma'
  firstname 'GW' lastname 'Shrubbery';
create user lorna password 'Mayday_domaka'
  tags (Street = 'Main Street', Number = '888');
alter user benny tags (shoesize = '8', hair = 'blond', drop weight);
alter current user set password 'SomethingEvenMoreSecretThanThis';
alter user dubya set inactive;
drop user ted;

For details on managing users through SQL, also see the Firebird 5.0 Language Reference, section SQL Statements for User Management.

The security database

Firebird user accounts are kept in a security database, which normally resides in the installation directory and is called security5.fdb (alias: security.db).Except in the case of so-called embedded connections (more about those later in this guide), connecting to a database always involves the security database, against which the user credentials are verified.Of course this is done transparently;the user doesn’t have to make an explicit connection to the security database.

However, in Firebird 5 this is not the end of the story.Firebird — since Firebird 3 — allows the use of multiple security databases on a system, each security database governing a specific set of databases.A database can even act as its own security database.

Showing how to set this up is outside the scope of this Quick Start Guide.You can find full details in the Firebird 3.0 Release Notes, chapter Security.But it is important to realise that if a system has multiple security databases, managing user accounts while connected to a database will always affect the accounts in the security database that governs that specific database.To be on the safe side, you may want to connect to the security database itself before issuing your user management commands.Connecting to the security database used to be forbidden in recent versions of Firebird, but is now once again possible, albeit by default only locally using embedded or — on Windows — XNET (which means that even the localhost route is blocked).

Appointing co-administrators

Tip

What follows here is not essential knowledge for beginners.You can skip it if you like and go on to the [qsg5-config-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:

create user bigbill password 'bigsekrit7foryou' grant admin role;
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.

Note
  • GRANT ADMIN ROLE and REVOKE ADMIN ROLE are not GRANT and REVOKE statements, although they look that way.They are clauses of 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:

    grant rdb$admin to littlejohn