The SQL SECURITY clause of various DDL statements enables executable objects (triggers, stored procedures, stored functions) to be defined to run in a specific context of privileges.

The SQL Security feature has two contexts: INVOKER and DEFINER. The INVOKER context corresponds to the privileges available to the current user or the calling object, while DEFINER corresponds to those available to the owner of the object.

The SQL SECURITY property is an optional part of an object’s definition that can be applied to the object with DDL statements. The property cannot be dropped, but it can be changed from INVOKER to DEFINER and vice versa.

This is not the same thing as SQL privileges, which are applied to users and some types of database objects to give them various types of access to other database objects. When an executable object in Firebird needs access to a table, view or another executable object, the target object is not accessible if the invoker does not have the necessary privileges on that object. That has been the situation in previous Firebird versions and remains so in Firebird 4.0. That is, by default all executable objects have the SQL SECURITY INVOKER property, and any caller lacking the necessary privileges will be rejected. The default SQL Security behaviour of a database can be overridden using ALTER DATABASE.

If a routine has the SQL SECURITY DEFINER property applied, the invoking user or routine will be able to execute it if the required privileges have been granted to its owner, without the need for the caller to be granted those privileges as well.

In summary:

• If INVOKER is set, the access rights for executing the call to an executable object are determined by checking the current user’s active set of privileges

• If DEFINER is set, the access rights of the object owner will be applied instead, regardless of the current user’s active set of privileges.