[kriszyp]

⊙ Problem

Reads through an @relationship did not always apply the role's permissions on the related table. REST and GraphQL select did. Conditions and sorts through a relationship, operations API get_attributes and *, reads without a select (@enumerable), property paths (/Emp/e1.dept) and $record did not.

🤔 Which read APIs does this cover?

REST (GET and QUERY), GraphQL and NoSQL operations searches. SQL and subscription deliveries still return related data unchecked; both are separate follow-ups.

💡 Solution

At admission, a read through a relationship needs read on the related table and on each related attribute it uses:

• REST and GraphQL refuse a denied condition or sort (403) and narrow selects, as before.
• A default or * read by a role that cannot read the @enumerable closure in full gets a written select that omits or narrows those relationships.
• The operations API refuses explicit references the way it refuses root ones.
• Super users and full-access roles see no change.

⚖️ Alternatives

• Check inside search and join code — no permissions there, and the operations API must refuse first.
• Route operations reads through allowRead — it narrows; the operations API must refuse and name the table.

🤔 Should an explicit REST select of an unreadable relationship fail?

No: REST keeps leaving it out, as for root attributes. Refusing would be a separate, visible change.

🤔 Does a partial reader pay a per-row cost?

Yes. Narrowing a partly readable @enumerable closure copies each row's * and projects the related record. Super users and full readers keep the raw path. Per-row time is not measured here; admission cost is, below.

🤔 Why do restricted roles' cycles stop per table, not per record?

The written select can only express a schema path. An Emp.manager chain stops at e2 for a restricted role: less data, never more. Per-record cut-offs are a follow-up.

🤔 May a role traverse a forward relationship it reads only through the foreign key?

Yes: the join reveals nothing beyond deptId, and the full-text suite relies on it. Inverse (to) relationships need their name.

🤔 Does a scalar sub-select keep its shape for restricted roles?

No: {name: 'dept', select: 'name'} returns {name} to a restricted role, as REST allowRead already does. Keeping the scalar would change select(id) on every relationship table.

🔧 Changes

• resources/Table.ts
  • _readDenial walks an attribute path through relationships and returns the first table or attribute the role cannot read. A forward step passes on a readable foreign key; full-text index names are left to search.
  • allowRead opens one admission scope on tables with relationships. authorizeRead refuses denied condition and sort paths, authorizes a property path as a scalar selection, and writes the default projection when the closure is restricted.
  • _readableInFull decides whether the role reads the @enumerable closure in full. Within one admission and one permission source, results are reused: failures, acyclic successes, and cycle successes once the outermost walk succeeds.
  • listEnumerableRelationships adds each enumerable relationship, narrowed or omitted, to a * marked RELATIONSHIPS_LISTED. A marked * copies what toJSON surfaces apart from relationships, in projection and in CSV columns.
  • _authorizeRelatedSelection is the per-relationship select step, shared with the operations bridge. It takes its authority from the request and checks the selection's own sort; plain JSON sub-selections stop at the containing attribute, matching resolver-free JSON projection.
  • $record carries its own table as its definition, so selecting it is authorized like the record.
• resources/Resource.ts: QUERY admission sees the body's conditions and sort, or a list body. A single-record marked * copies unlisted attributes. A live subscription filtered or sorted through a relationship is rechecked on its own.
• utility/operation_authorization.ts: normalizeSearchRequest rewrites a search to what its handler runs. checkRelationshipReads finds denied relationship paths and reportRelationshipDenials reports them in the root-reference shape; root-table denials go to the root attribute check. The non-super * rewrite drops denied relationships.
• dataLayer/harperBridge/ResourceBridge.ts: getSelect narrows related records in one admission scope.
• resources/DESIGN.md, DESIGN.md: design note and index entry.

✅ Verification

Tests, base check, cost and gates

• Integration suite relationship-related-table-permissions.test.ts (fixture schema: Emp → Dept and Seat → Dept @enumerable, REST and GraphQL on; full, Emp-only, attribute-restricted and two write-only roles; super user): 25 cases pass (operations, REST, GraphQL, QUERY, default reads, $record, property paths, * placement in operations, refusal bodies). On the merge base, 21 of the first 23 fail; 2 are full-access controls.
• Unit: enumerableRelationshipPermissions.test.js (22 cases: default reads, cycles, CSV, $record, *, mutable instances, source records, operations refusal shape, nested conditions through a foreign key, and permission-lookup bounds — 14 of the first 18 fail on merge base), permissions.test.js, operation_authorization.test.js, liveSubscriptionAuth.test.js, nestedSelectMissingValues.test.js.
• Cost (bench-run, turbo off, admission of an empty read): no relationships 22–25 ns; depth-2 @enumerable, full role, 93 ns; depth 40 3.0 µs; restricted role writing select 0.85 µs at depth 2, 26 µs at depth 40; 1,000 relationships 275 µs. Cost is per request, not per record.
• At 06211c072 (on main 9c43c7790): focused unit suites 559 pass; this PR's integration file 25/25; typecheck, lint:required and build clean. Before rebase (8a1355f42): test:unit:main 7282 pass, test:unit:resources 4383 pass, test:integration:all 2551 pass.

• PR QA: skipped @ c07bc1d — the PR QA queue is not reachable from dispatch tasks on this worker.

— Claude Opus 5.5

_{🤖 Generated by Anthropic Claude (Claude Code dev-agent); posted via @kriszyp.}

🤖 Generated with Claude Code

https://claude.ai/code/session_01LHGnpcz4RLmn8aGcGZa62A

Release target: main — changes which reads several APIs allow; a release-line backport is a separate customer-need call
Related PRs: #3279 overlaps (allowRead relationship loop), #3137 overlaps (subscription verdict sharing), #3297 overlaps (primary-key grant vs related narrowing), #3307 overlaps (subscription delivery attribute projection), #3456 overlaps (nested-JSON projection scope), #3497 overlaps (Resource read admission for delegated gets), #3221 overlaps (both change select projection), #3615 overlaps (relationship resolution), #3619 overlaps (relationship resolution), #3651 overlaps (nested selector permission isolation), #3775 overlaps (relationship query projection and sorts), #3779 overlaps (allowRead writes the authorized select onto the query object), 36 others independent
Complexity: complicated

Deferred findings

• 82822c63a1b8a158 major security — resources/Table.ts — Non-relationship property path returns an attribute the role cannot read — NOT FILED
• 258d69f5dbefb9d8 major security — resources/Table.ts — Subscription delivery serializes unauthorized enumerable relationships — NOT FILED
• 559f5ddf6e5a5f31 minor security — resources/Table.ts — REST allows condition/sort on an unreadable root attribute — NOT FILED
• 2edc9ecaaeec7e7a minor correctness — resources/Table.ts — All-denied relationship property set substitutes default projection — NOT FILED
• 6857402ed7b3795f minor security — utility/operation_authorization.ts — SQL joins bypass related-table read checks — NOT FILED
• 3400948cb3aded79 nit correctness — resources/Resource.ts — Static entry consumes the first condition of a one-shot iterator target — NOT FILED
• 2c0ec0e07b5a3b82 none test-coverage — integrationTests/security/relationship-related-table-permissions.test.ts — Removed full-role dept{name} HTTP assertion — NOT FILED

Origin — the dispatch brief this PR was written from

Make @relationship traversal apply the related table's role permissions everywhere, matching what REST/GraphQL select expansion already does through Table.allowRead (resources/Table.ts ~3534-3550, only when checkPermission is set). Two paths do not do this today. (1) Operations API reads: a get_attributes entry that names a relationship, and the non-super get_attributes:['*'] rewrite in utility/operation_authorization.ts (~889-909, which also lists relationship attributes), resolve the related records through dataLayer/harperBridge/ResourceBridge.ts without checking the role's permission on the related table or its attribute_permissions. (2) Filter conditions whose path goes through a relationship (REST ?rel.attr=..., GraphQL nested arguments, ops search_by_conditions with search_attribute: ['rel','attr']) are evaluated in resources/search.ts (~897-949, ~1597-1700) against the related table without that check. Required behaviour: a role with no read on the related table gets the relationship omitted from *, and an explicit reference (select or condition) to it is refused like a reference to any unreadable table; attribute_permissions of the related table apply to sub-selects and condition attributes.

Acceptance

Integration tests with tables Emp and Dept (Emp.dept @relationship to Dept), roles: full access to both; Emp only; Emp + Dept with attribute_permissions. Ops get_attributes naming the relationship, ops '', REST select, REST/GraphQL/ops conditions on a Dept attribute: Emp-only role is refused (explicit) or the relationship omitted (''); attribute-restricted Dept role sees only permitted Dept attributes; full-access role and super user unchanged. Shown failing on origin/main.

_{Dispatch: task harper-relationship-related-table-permissions · queued by finding-triage/wave-36 · ran by claude/opus/high · worker kzyp-xps-1}

Late Grok findings

none surviving — Grok reviewed a8f9b09

No finding survived adjudication.

Not standing: none. Grok ran 16m (16m from launch to report); the fold adjudication (cursor-grok@a8f9b0969407-e6482412, claude) took 1m.

Late Grok findings

1 surviving (highest minor) — Grok reviewed c07bc1d

• minor — resources/Table.ts:2255 — on a default read that allowRead marks RELATIONSHIPS_LISTED, _copyUnlistedAttributes copies with selected[key] = record[key]. If the stored record has its own __proto__ data key, that assignment goes through Object.prototype's setter. A primitive value is discarded, and an object value b

Not standing: 1 dropped-factually-wrong. Grok ran 18m (18m from launch to report); the fold adjudication (cursor-grok@c07bc1d7cadb-c4f54c7d, claude) took 2m.

_{Review-Coverage: authored=claude; ran=cursor-composer,codex,gemini,cursor-grok; late=cursor-grok:adjudicated; adjudicated=domain,domain(codex); declined=cursor-kimi,cursor-muse,muse; rounds=27; full=8 @ 06211c0}

_{Review-Attention: deep ~70m (critical: ResourceBridge.ts, Table.ts; hot: Resource.ts; decisions: do-less-alternative, enumerable-default-narrow-vs-refuse, ops-star-position-semantics, forward-key-grants-hop, denied-as-nonexistent, table-level-cycle-cut) @ 06211c0}

[gemini-code-assist]

Code Review

This pull request implements authorization checks for @relationship reads, ensuring that users have the required permissions on related tables and attributes. The changes introduce new methods in TableResource for read denial and selection authorization, update operation_authorization.ts to enforce these checks during search operations, and include integration tests and updated design documentation. The review feedback identifies several potential bugs where input strings could be incorrectly treated as iterables, providing actionable code suggestions to add explicit type checks and adhere to the repository's null-check style guide.