Which role takes precedence when users have overlapping privileges?

Direct answer

No role takes precedence. Firebird evaluates overlapping role privileges additively: the effective permission set is the union of all privileges held by every active role, plus any privileges granted directly to the user account. There is no role hierarchy, priority sequence, or deny rule that lets one role override another.

Version assumption: Firebird 2.5, 3.x, and 4.x; SET ROLE behavior is effectively the same for this question across those releases.

Confirmed behavior versus likely explanation

Confirmed behavior

• Access succeeds when at least one active role, or the user account itself, holds the required privilege.
• A missing privilege in one role does not cancel the same privilege granted by another active role.
• Firebird roles support grants only; they do not support deny rules that override another role's grant.
• SYSDBA and the object owner typically bypass standard RBAC checks.

Likely explanation for confusion

Administrators often expect a “most restrictive role wins” model. Firebird does not implement that model; overlapping grants simply accumulate.

Steps for this case

1. Identify the roles assigned to the user.
2. Activate the roles in the session, for example SET ROLE role_name; or SET ROLE ALL;.
3. Test the object access as that user.
4. If access is denied, confirm whether the required privilege exists on any active role or on the user account directly.

Missing diagnostic detail

Are both roles activated in the current session with SET ROLE? If not, their privileges do not contribute to the effective set, and the recommendation changes from “overlapping grants are additive” to “activate the roles first.”

Verification

CREATE ROLE role_a;
CREATE ROLE role_b;
GRANT SELECT ON table_x TO role_a;
GRANT INSERT ON table_x TO role_b;
GRANT role_a, role_b TO user_y;
-- Connect as user_y
SET ROLE role_a;
SET ROLE role_b;
SELECT * FROM table_x; -- expected to succeed
INSERT INTO table_x ...; -- expected to succeed

Then revoke SELECT from role_a and repeat the SELECT test. Access should still succeed only if role_b or user_y independently holds SELECT.