A PERMISSIONS ... WHERE clause is evaluated with permission enforcement disabled, so it can't recurse into its own checks. But the clause could also contain data-modifying statements, and these ran with enforcement still off — so evaluating a permission check could write to tables the caller cannot write.
For example:
DEFINE TABLE post PERMISSIONS FOR update
WHERE (CREATE log SET at = time::now()) OR true;Any user allowed to update a post now also creates a log record, even with no permission on log. The clause is evaluated once per matched record, so one statement can cause several writes.
Impact
Only databases with a PERMISSIONS clause that contains a write are affected; FULL, NONE, and read-only clauses are not.
What an attacker can do:
- With permission to perform the guarded operation (a low-privileged or record user is enough), write to tables in their own database that their permissions would otherwise forbid, by triggering an operation the clause guards.
- Cause several writes from a single statement — the clause is evaluated once per matched record.
- Trigger unintended events, cascades, or data corruption on those tables.
What it can't do:
- Escape the caller's own namespace and database — a permission clause cannot switch namespace or database.
- Perform root- or namespace-level actions such as creating users; the caller's role still applies.
- Read hidden data — this is an integrity issue, not disclosure.
Patches
Permission clauses must now be read-only: defining or importing one that contains a write is rejected, and any write attempted while a clause is evaluated is blocked at runtime, including writes reached through a called function. Read-only clauses are unaffected.
- Versions 3.2.0 and later are not affected by this issue.
Workarounds
Users unable to patch should consider the following workarounds:
- Review your
PERMISSIONS clauses and remove any containing CREATE, UPDATE, DELETE, RELATE, INSERT, or UPSERT.
- Limit who can define schema and vet imported data — such a clause must be defined before it can be triggered.
Resources
Acknowledgements
Thank you to sondt99 for reporting this issue.
References
sondt99 Reporter
A
PERMISSIONS ... WHEREclause is evaluated with permission enforcement disabled, so it can't recurse into its own checks. But the clause could also contain data-modifying statements, and these ran with enforcement still off — so evaluating a permission check could write to tables the caller cannot write.For example:
Any user allowed to update a
postnow also creates alogrecord, even with no permission onlog. The clause is evaluated once per matched record, so one statement can cause several writes.Impact
Only databases with a
PERMISSIONSclause that contains a write are affected;FULL,NONE, and read-only clauses are not.What an attacker can do:
What it can't do:
Patches
Permission clauses must now be read-only: defining or importing one that contains a write is rejected, and any write attempted while a clause is evaluated is blocked at runtime, including writes reached through a called function. Read-only clauses are unaffected.
Workarounds
Users unable to patch should consider the following workarounds:
PERMISSIONSclauses and remove any containingCREATE,UPDATE,DELETE,RELATE,INSERT, orUPSERT.Resources
fix(core): reject writes in PERMISSIONS clauses and block writes during permission evaluation(included in SurrealDB 3.2.0)Acknowledgements
Thank you to sondt99 for reporting this issue.
References