Security Model

From InterBase

Go Up to Database User Management

Security for InterBase relies on a central security database for each server host. This database, admin.ib by default, contains a record for each legitimate user who has permission to connect to databases and InterBase services on that host. Each record includes the user login name and the associated encrypted password. The entries in this security database apply to all databases on that server host.

The username is significant to 31 bytes and is not case sensitive. When a stronger password protection is implemented, the password is now significant to 32 bytes instead of 8 and is case sensitive.

Before performing any database administration tasks, you must first log in to a server. Once you log in to a server, you can then connect to databases residing on the server.

All users must enter their username and password to log in to a server. The password is encrypted for transmission over the network. The username and password are verified against records in the security database. If a matching record is found, the login succeeds.


Every InterBase server has a SYSDBA user, with default password masterkey. SYSDBA is a special user account that can bypass normal SQL security and perform tasks such as database backups and shutdowns.

Initially, SYSDBA is the only authorized user on a server; the SYSDBA must authorize all other users on the server. Only the SYSDBA user can update the security database to add, delete, or modify user configurations. SYSDBA can use either gsec or IBConsole to authorize a new user by assigning a username and password in the security database.

We strongly recommend you change the password for SYSDBA as soon as possible after installing InterBase. If you do not alter the SYSDBA password, unauthorized users have easy access and none of your databases are secure.

Other Users

The SYSDBA account can create other users on a per-server basis. Use gsec or IBConsole to create, modify, or remove users from the InterBase security database. These users are authorized to connect to any database on that database server host. It is a common design strategy to create a distinct InterBase user for each person who uses the databases on your server. However, other strategies are also legitimate. For example:

  • Create one InterBase user for an entire group of people to use, in order to simplify password administration. For example, a user FINANCE could satisfy the access needs for any and all staff in a financial analysis team. This team only needs to remember one password between them.
  • Create one InterBase user for a group of people to use, as warranted by requirements of distinct privilege configurations. For example, if Erin and Manuel have identical access to the data within a database, they could use the same InterBase user account.

Users on UNIX

If both the client and the server are running UNIX, you can allow UNIX usernames access to databases by configuring the server host to treat the client host as a trusted host.

To establish a trusted host relationship between two hosts, add an entry in /etc/hosts.equiv or /etc/gds_hosts.equiv on the server. The former file establishes trusted host status for any service (for example, rlogin, rsh, and rcp); the latter file establishes trusted host status for InterBase client/server connections only. The format of entries in both files is identical; see your operating system documentation on hosts.equiv for details.

The login of the client user must exist on the server. In addition to the hosts.equiv method of establishing a trusted host, the you can also use the .rhosts file in the home directory of the account on the server that matches the account on the client.

The InterBase client library defaults to using the current client’s UNIX login as the InterBase login only when the client specifies no username through any of the following methods:

  • Database parameter buffer (dpb) parameters – see the API Guide.
  • Command-line options – for example, -user options of isql or another utility
  • Environment variables – see ISC_USER and ISC_PASSWORD.


  • This feature is not implemented on Windows servers, because Windows does not implement a trusted host mechanism as UNIX does.
  • Windows clients cannot be treated as trusted hosts by UNIX servers.

See Also

Advance To: