+ "details": "### Summary\n\nWhen using **filter** authorization, two edge cases could cause the policy compiler/authorizer to generate a permissive filter:\n\n1. **Bypass policies whose condition can never pass at runtime** were compiled as\n `OR(AND(condition, compiled_policies), NOT(condition))`.\n If the condition could never be true at runtime, the `NOT(condition)` branch evaluated truthy and the overall expression became permissive.\n\n2. **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.\n\nThese bugs could allow reads to return records that should have been excluded by policy.\n\n### Impact\n\nProjects that rely on **filter-based authorization** and define:\n\n* `bypass ... do ... end` blocks whose condition(s) are only resolvable at runtime and can never pass in a given request context, **or**\n* runtime checks that simplify to an **empty** scenario for a clause\n\nmay unintentionally generate a permissive query filter, potentially returning unauthorized data.\n\n*Actions primarily affected:* reads guarded by filter policies. Non-filter (e.g., hard forbid) policies are not impacted.\n\n### Technical details\n\nThis patch corrects two behaviors:\n\n* **`Ash.Policy.Policy.compile_policy_expression/1`** now treats **bypass** blocks as\n `AND(condition_expression, compiled_policies)`\n instead of `OR(AND(...), NOT(condition_expression))`. This removes the permissive `NOT(condition)` escape hatch when a bypass condition never passes.\n\n* **`Ash.Policy.Authorizer`** now treats **empty SAT scenarios** (`scenario == %{}`) as **`false`**, ensuring impossible scenarios do not collapse into a no-op and inadvertently widen the filter. The reducer also normalizes `nil` → `false` consistently when building `auto_filter` fragments.\n\nRelevant changes are in:\n\n* `lib/ash/policy/policy.ex` (bypass compilation)\n* `lib/ash/policy/authorizer/authorizer.ex` (scenario handling / auto_filter normalization)\n* Tests added: `test/policy/filter_condition_test.exs` (`RuntimeFalsyCheck`, `RuntimeBypassResource`) validate the corrected behavior.\n\n### Workarounds\n\n* Avoid `bypass` policies whose conditions are only decidable at runtime and may be perpetually false in some contexts; prefer explicit `authorize_if`/`forbid_if` blocks without `bypass` for those cases.\n* Add an explicit **final `forbid_if always()`** guard for sensitive reads as a belt-and-suspenders fallback until user can upgrade.\n* Where feasible, replace runtime-unknown checks with strict/compile-time checks or restructure to avoid empty SAT scenarios.\n\n### How to tell if user is affected\n\nUser is likely affected if ALL of the following are true:\n\n* Uses **filter authorization**; and\n* Defines `bypass` block with `access_type :runtime` without any policies after it; or\n* Defines `bypass` blocks whose conditions are evaluated at runtime (e.g., checks with `strict_check/3` returning `:unknown` and a runtime `check/4` that may never succeed in some contexts) without any policies after it\n\nA quick sanity test is to issue a read expected to return **no** rows under such a bypass or runtime-falsy condition and verify it indeed returns `[]`. The included test `bypass works with filter policies` demonstrates the corrected, non-permissive behavior.",
![advisory-database[bot]](https://avatars.githubusercontent.com/in/21409?v=4&size=40){kind=avatar}
0 commit comments