Skip to content

Review policy falls back to the open default when the schema or the file's object cannot be read #4647

Open

Description

@WilcoLouwerse

Found during a Strict review of #4580 (development → beta promotion). Present on development; introduced in #4595.

Impact

A decision on a decider-owned schema becomes changeable or visible under the open instance default whenever a lookup throws (schema read, or the file-to-object lookup). Needs a transient failure, but it fails open on a permission rule.

The chain

When the schema cannot be read, the resolver returns ownership: decider with no supervisors and calls that "fail closed", but hideOthers stays false, so DecisionVisibility::isHidden() returns false and another reviewer sees the verdict, bases and decision record that the schema declared hidden. The second catch (subjectOf(), line 142) is worse: if the file-to-object lookup throws, the schema is lost and the instance default applies, which is fully open when unset, so a hidden, decider-owned policy is dropped for the request. Ownership and visibility disagree on what a failure means, and testAnUnreadableSchemaFailsClosed asserts only ownership.

lib/Service/Decision/ReviewPolicyResolver.php:98 — verified against b9e5d8df40.

Reproduction

Verified by reading the code at b9e5d8df40; not executed (no vendor tree, no rig in the review).
Verification: grep -n "hideOthers\|hidesOthers" tests/Unit/Service/Decision/ReviewPolicyResolverTest.php → no assertion on hidesOthers for the failure case

Suggested direction

On the schema-read failure build the policy with hideOthers: true as well; in subjectOf() let a lookup failure fail closed (decider-owned, hide others) instead of falling to the instance default. Unit seam: ReviewPolicyResolverTest: unreadable schema and throwing rootFolder cases.

Done when: with an unreadable schema, hidesOthers() is true; with a throwing rootFolder, forRelation returns a decider-owned policy that hides others

Review thread

#4580 (comment)

Fix

Proposed in #4655 (not merged yet).

Activity

  1. added
    bugSomething isn't working
    securityA user can read or write what they must not
    on Oct 15, 2026
  2. github-actions commented on Oct 15, 2026

    @github-actions
    Contributor

    Thank you for opening this issue! It has been assigned to @rubenvdlinde for review.

    What happens next:

    1. A maintainer will review this issue and determine the appropriate action
    2. If accepted, it may be converted into an OpenSpec change for structured development
    3. You will be notified of any status changes

    Triage labels:

    • triage:accept-feature — accepted as a new feature
    • triage:accept-bugfix — accepted as a bug fix
    • triage:needs-info — more information needed
    • triage:wontfix — will not be addressed
    • triage:duplicate — duplicate of another issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

bugSomething isn't workingsecurityA user can read or write what they must nottriageAwaiting triage

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions