Summary
When using filter authorization, two edge cases could cause the policy compiler/authorizer to generate a permissive filter:
-
Bypass policies whose condition can never pass at runtime were compiled as
OR(AND(condition, compiled_policies), NOT(condition)).
If the condition could never be true at runtime, the NOT(condition) branch evaluated truthy and the overall expression became permissive.
-
Runtime policy scenarios that reduce to “no checks are applicable” (an empty SAT scenario) were treated as an empty clause and dropped instead of being treated as false, which could again produce an overly broad (permissive) filter.
These bugs could allow reads to return records that should have been excluded by policy.
Impact
Projects that rely on filter-based authorization and define:
bypass ... do ... end blocks whose condition(s) are only resolvable at runtime and can never pass in a given request context, or
- runtime checks that simplify to an empty scenario for a clause
may unintentionally generate a permissive query filter, potentially returning unauthorized data.
Actions primarily affected: reads guarded by filter policies. Non-filter (e.g., hard forbid) policies are not impacted.
Technical details
This patch corrects two behaviors:
-
Ash.Policy.Policy.compile_policy_expression/1 now treats bypass blocks as
AND(condition_expression, compiled_policies)
instead of OR(AND(...), NOT(condition_expression)). This removes the permissive NOT(condition) escape hatch when a bypass condition never passes.
-