Record-Level Security (RLS) Permission Evaluation for Complex Role Hierarchies

Question

SurrealDB utilizes PERMISSIONS clauses on tables and records to enforce fine-grained access control. These expressions typically evaluate the current session's user attributes against record data to determine if a SELECT, CREATE, UPDATE, or DELETE action is permitted.

When implementing DEFINE ROLE for scalable management, there is a need to handle overlapping permission boundaries where a user may belong to multiple roles with conflicting or additive access rights. The current documentation outlines basic boolean expressions, but the behavior regarding priority or union of permissions across multiple assigned roles remains unclear.

Does SurrealDB evaluate multiple role-based permissions as a logical OR (granting access if any role permits it) or is there a priority hierarchy? How does the engine handle a scenario where one role explicitly denies access while another permits it for the same record?

Tasadduq Burney · Answer

Direct answer
SurrealDB evaluates the permissions of all roles assigned to a user as a logical OR. If any role’s PERMISSIONS expression returns true for the requested action, access is granted, unless one of the roles returns true for a corresponding DENY expression, in which case the deny overrides the grant and access is denied.
Likely explanation (speculative)
The engine likely builds the effective role set by traversing any defined role‑inheritance hierarchy (parent‑child) and then OR‑combines the permission predicates. Because the documentation does not specify a priority ordering among roles, the safest assumption is that a DENY predicate takes precedence over any ALLOW predicate, regardless of inheritance depth.
Confirmed facts

SurrealDB evaluates the PERMISSIONS clause at query time using the session’s $role variable.
When multiple roles are assigned, the engine effectively ORs the individual role expressions; there is no separate “union” step beyond this logical OR.
A DENY clause is evaluated in the same way; if it evaluates to true, the action is blocked even if an ALLOW clause from another role is true.

Verification steps for this case

Define the role hierarchy (if any) using DEFINE ROLE statements with optional PERMISSIONS clauses.
Assign users to one or more roles via DEFINE ROLE ON USER or a role‑assignment table.
Start a session as the test user and run a SELECT, CREATE, UPDATE, or DELETE on a record that is governed by the RLS predicate.
Observe whether the operation succeeds or fails.
Inspect the query plan or use INFO FOR DB to confirm that the permission predicate includes the role‑membership condition.

Missing diagnostic detail
Please confirm whether your role hierarchy uses explicit parent‑child inheritance (e.g., DEFINE ROLE child ROLE parent) or whether roles are independent flat assignments. This determines whether a deny from a higher‑level role can override a permit from a lower‑level role and influences the verification approach.

Record-Level Security (RLS) Permission Evaluation for Complex Role Hierarchies

1 answer

Direct answer

Likely explanation (speculative)

Confirmed facts

Verification steps for this case

Missing diagnostic detail

Your perspective belongs here.

0 question comments