FirebirdSQL logo

The second level of Firebird’s security model is SQL privileges. Whilst a successful login — the first level — authorises a user’s access to the server and to all databases under that server, it does not imply that the user has access to any objects in any databases. When an object is created, only the user that created it (its owner) and administrators have access to it. The user needs privileges on each object they need to access. As a general rule, privileges must be granted explicitly to a user by the object owner or an administrator of the database.

A privilege comprises a DML access type (SELECT, INSERT, UPDATE, DELETE, EXECUTE and REFERENCES), the name of a database object (table, view, procedure, role) and the name of the grantee (user, procedure, trigger, role). Various means are available to grant multiple types of access on an object to multiple users in a single GRANT statement. Privileges may be revoked from a user with REVOKE statements.

An additional type of privileges, DDL privileges, provide rights to create, alter or drop specific types of metadata objects. System privileges provide a subset of administrator permissions to a role (and indirectly, to a user).

Privileges are stored in the database to which they apply and are not applicable to any other database, except the DATABASE DDL privileges, which are stored in the security database.

The Object Owner

The user who created a database object becomes its owner. Only the owner of an object and users with administrator privileges in the database, including the database owner, can alter or drop the database object.

Administrators, the database owner or the object owner can grant privileges to and revoke them from other users, including privileges to grant privileges to other users. The process of granting and revoking SQL privileges is implemented with two statements, GRANT and REVOKE.