On POSIX systems, including MacOSX, Firebird will interpret a POSIX user account as though it were a Firebird user account in its own security database, provided the server sees the client machine as a trusted host and the system user accounts exist on both the client and the server. To establish a trusted relationship with the client host, the corresponding entries must be included in one of the files /etc/hosts.equiv or /etc/gds_hosts.equiv on Firebird’s host server.

• The file hosts.equiv contains trusted relationships at operating system level, encompassing all services (rlogin, rsh, rcp, and so on)

• The file gds_hosts.equiv contains trusted relationships between Firebird hosts only.

The format is identical for both files and looks like this:

  |hostname [username]

On Windows server-capable operating systems, operating system accounts can be used. Trusted Authentication must be enabled by setting the Authentication parameter to Trusted or Mixed in the configuration file, firebird.conf.

Even with trusted authentication enabled, Windows operating system Administrators are not automatically granted SYSDBA privileges when they connect to a database. To make that happen, the internally-created role RDB$ADMIN must be altered by SYSDBA or the database owner, to enable it. For details, refer to the later section entitled Section 11.1.2.3, “AUTO ADMIN MAPPING”.

The embedded version of Firebird server on Windows does not use server-level authentication. However, because objects within a database are subject to SQL privileges, a valid user name and, if applicable, a role, may be required in the connection parameters.

The owner of a database is either the user who was CURRENT_USER at the time of creation or, if the parameters USER and PASSWORD were supplied in the CREATE DATABASE statement, the user cited there.

Owner is not a user name. The user who is the owner of a database has full administrator rights with respect to that database, including the right to drop it, to restore it from a backup and to enable or disable the Section 11.1.2.3, “AUTO ADMIN MAPPING” capability.

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:

  |CREATE USER new_user
  |  PASSWORD 'password'
  |  GRANT ADMIN ROLE;
  | 
  |ALTER USER existing_user
  |  GRANT ADMIN ROLE;
  | 
  |ALTER USER existing_user
  |  REVOKE ADMIN ROLE;

The grantor must be already logged in as an administrator.

See alsoSection 11.1.4.1, “CREATE USER”, Section 11.1.4.2, “ALTER USER”

  |gsec -add new_user -pw password -admin yes
  |gsec -mo existing_user -admin yes
  |gsec -mo existing_user -admin no

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

  |GRANT RDB$ADMIN TO username
  | 
  |REVOKE RDB$ADMIN FROM username

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

See alsoSection 11.2.2.1, “GRANT”, Section 11.2.3.1, “REVOKE”

In Firebird 2.1, Windows Administrators would automatically receive SYSDBA privileges if trusted authentication was configured for server connections. In Firebird 2.5, it is no longer automatic. The setting of the AUTO ADMIN MAPPING switch now determines whether Administrators have automatic SYSDBA rights, on a database-by-database basis. By default, when a database is created, it is disabled.

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.

  |ALTER ROLE RDB$ADMIN
  |  SET AUTO ADMIN MAPPING;  -- enable it
  | 
  |ALTER ROLE RDB$ADMIN
  |  DROP AUTO ADMIN MAPPING; -- disable it

  |gsec -mapping set
  | 
  |gsec -mapping drop

Used forCreating a Firebird user account

Available inDSQL

Syntax

  |CREATE USER username PASSWORD 'password'
  |  [FIRSTNAME 'firstname']
  |  [MIDDLENAME 'middlename']
  |  [LASTNAME 'lastname']
  |  [GRANT ADMIN ROLE]

Use a CREATE USER statement to create a new Firebird user account. The user must not already exist in the Firebird security database, or a primary key violation error message will be returned.

The username argument must follow the rules for Firebird regular identifiers: see Identifiers in the Structure chapter. User names are always case-insensitive. Supplying a user name enclosed in double quotes will not cause an exception: the quotes will be ignored. If a space is the only illegal character supplied, the user name will be truncated back to the first space character. Other illegal characters will cause an exception.

The PASSWORD clause specifies the user’s password. A password of more than eight characters is accepted with a warning but any surplus characters will be ignored.

The optional FIRSTNAME, MIDDLENAME and LASTNAME clauses can be used to specify additional user properties, such as the person’s first name, middle name and last name, respectively. They are just simple VARCHAR(31) fields and can be used to store anything you prefer.

If the GRANT ADMIN ROLE clause is specified, the new user account is created with the privileges of the RDB$ADMIN role in the security database (security2.fdb). It allows the new user to manage user accounts from any regular database he logs into, but it does not grant the user any special privileges on objects in those databases.

To create a user account, the current user must have administrator privileges in the security database. Administrator privileges only in regular databases are not sufficient.

See alsoSection 11.1.4.2, “ALTER USER”, Section 11.1.4.3, “DROP USER”

Used forModifying a Firebird user account

Available inDSQL

Syntax

  |ALTER USER username [SET]
  |  [PASSWORD 'password']
  |  [FIRSTNAME 'firstname']
  |  [MIDDLENAME 'middlename']
  |  [LASTNAME 'lastname']
  |  [{GRANT | REVOKE} ADMIN ROLE]

Use an ALTER USER statement to edit the details in the named Firebird user account. To modify the account of another user, the current user must have administrator privileges in the security database. Administrator privileges only in regular databases are not sufficient.

Any user can alter his or her own account, except that only an administrator may use GRANT/REVOKE ADMIN ROLE.

All of the arguments are optional but at least one of them must be present:

• The PASSWORD parameter is for specifying a new password for the user

• FIRSTNAME, MIDDLENAME and LASTNAME allow updating of the optional user properties, such as the person’s first name, middle name and last name respectively

• Including the clause GRANT ADMIN ROLE grants the user the privileges of the RDB$ADMIN role in the security database (security2.fdb), enabling him/her to manage the accounts of other users. It does not grant the user any special privileges in regular databases.

• Including the clause REVOKE ADMIN ROLE removes the user’s administrator in the security database which, once the transaction is committed, will deny that user the ability to alter any user account except his or her own

See alsoSection 11.1.4.1, “CREATE USER”, Section 11.1.4.3, “DROP USER”

Used forDeleting a Firebird user account

Available inDSQL

Syntax

  |DROP USER username

Use the statement DROP USER to delete a Firebird user account. The current user requires administrator privileges.

ExampleDeleting the user bobby:

  |DROP USER bobby;

See alsoSection 11.1.4.1, “CREATE USER”, Section 11.1.4.2, “ALTER USER”