fix: the delivery gate consults the node type's own access rule (#3061) by rbuergi · Pull Request #3100 · Systemorph/MeshWeaver

rbuergi · 2026-09-02T10:56:50Z

The defect

ValidateDeleteRequest carries [RequiresPermission(Permission.Delete)]. The delivery gate
(AccessControlPipeline) evaluates it through RequiresPermissionAttribute.GetPermissionChecks,
whose default implementation is literally yield return (hubPath, Permission) — a raw Delete
on the satellite's own path. It never consulted INodeTypeAccessRule.

ActivityNodeType (and every other satellite type) registers SatelliteAccessRule, which maps a
satellite's Delete to Permission.Update on its MainNode — creating a satellite is a
modification of its main node, and so is removing it. #2913 reconciled exactly that mismatch in
the delete pre-flight (MeshExtensions.CheckDeletePermissionForNode) but not in the delivery gate,
which runs first — so the gate won.

Measured on production (memex.systemorph.com, 2026-09-02): a recursive delete of the orphan NodeType
Edu/Course refused with

Access denied: user 'rbuergi' lacks Delete permission on 'Edu/Course/_Activity/compile-…'

for all 72 of its _Activity satellites — a check the node's own registered rule says should pass.
The one repair for a dangling NodeType was therefore unavailable through any API.

The fix

One shared seam so the two cannot drift again. New
NodeTypeAccessRuleGate (src/MeshWeaver.Mesh.Contract/Services/NodeTypeAccessRuleGate.cs) owns
resolution and evaluation — the three terminals (verdict / fault / completed-without-emitting), the
TakeDecisionOutsideGate hop, and the "the caller-visible detail names the exception TYPE, never its
message" rule. CheckDeletePermissionForNode and CheckDeletePermissionByRule were rewritten to
call it (they used to write the evaluation out inline — which is how the seams diverged), and
AccessControlPipeline now calls it too.

Where the reconsideration sits in the gate, reached ONLY from a definitive denial:

Fold outcome for `(hubPath, Permission)`	What happens
Granted	delivered — the rule is never consulted, so a hot `SubscribeRequest` reads no node
Denied	re-decided through the node type's rule — the rule's answer is the gate's answer
Undetermined	refused as `Unavailable` — "we could not check" is not a rule question

Four conditions leave the denial exactly as it was: the check is not on this hub's own path; the
permission names no operation a rule can decide about that node; nothing is served at that path; or
no rule governs (node type, operation).

Permission.Create deliberately maps to no operation: a create names a node that does not exist
yet and the gate evaluates on the PARENT's hub path, so the type a lookup here would find is the
parent's, and the parent's rule has no standing over a child's creation. Everything outside the CRUD
four maps to nothing for the matching reason — INodeTypeAccessRule.SupportedOperations is expressed
in NodeOperations.

No skip-trapdoor: a node read that FAULTS answers Undetermined, never the original denial.
Falling back to the denial would let a transient storage fault silently restore the pre-fix
behaviour — the gate's own input deciding whether the gate ran.

Verification

dotnet build … -c Release -warnaserror, one project per invocation, 0 Error(s) / 0 Warning(s)
on all nine touched-or-dependent projects.
The test fails without the fix and passes with it. With AccessControlPipeline.cs reverted to
origin/main and everything else in place, AnEditorsSatellitePreflight_IsNotRefusedByTheGate
fails with the production message verbatim:
Access denied: user 'satellite-editor' lacks Delete permission on 'SatelliteDeleteGate/Doc/_Activity/run1'.
Full unfiltered runs (never --filter, so the ratchet guards actually run) of
MeshWeaver.Graph.Test, MeshWeaver.Documentation.Test, MeshWeaver.Hosting.Test,
MeshWeaver.Security.MeshTest, MeshWeaver.Data.Test, MeshWeaver.Messaging.Hub.Test.

SatelliteDeliveryGateTest pins three verdicts on one mesh, so a fix that merely widened Delete
would fail two of them: the Editor's satellite pre-flight is served; a Viewer's is still refused
Unauthorized (the rule DENIES — consulting a rule never means granting); and the same Editor at a
plain Markdown child of the same node is still refused (no rule, nothing widened).

No band-aids

No timeout was raised, no retry added, no non-answer treated as consent, no permission widened. The
only behaviour change is that a denial on a rule-governed node type is now decided by that rule —
the same authority the delete pre-flight has consulted since #2913.

Docs

Doc/Architecture/AccessControl.md — the paragraph that used to say the message-level gate was
deliberately not routed through the rule ("a separate decision with a much larger blast radius; it
has not been made") is replaced with the decision, the measurement, the ordering table and the two
deliberate exclusions. Plus a Category: Fix What's New entry.

🚩 One thing that does NOT fully reconstruct, and the maintainer asked to hear it

The mechanism is confirmed and now pinned by a test that reproduces the production message verbatim.
The production grant topology, however, does not by itself explain the reported denial, and I
could not close that gap read-only:

Edu/_Access holds exactly three assignments — system-security, Public — Viewer,
Anonymous — Viewer. There is no rbuergi grant anywhere under Edu, no root _Access
grant for rbuergi (his 34 assignments are all per-partition; the platform-admin one is
Admin/_Access, which by design confers no data access), and zero GroupMembership nodes.
Edu/_Policy is { publicRead: true } — no cap, no breaksInheritance.
The delete nevertheless reached the pre-validate-descendants stage, which only happens after
the ROOT check (Delete on Edu/Course.MainNode ?? Path = Edu/Course) has passed.
GetScopeHierarchy is a plain path walk, so any inheritable Delete grant that let the root
through would also have covered Edu/Course/_Activity/compile-… — and the gate would have granted
there too.

So the grant that let the root through is not visible in the mesh's AccessAssignment rows —
most likely a static assignment seeded into the deployment (CollectStaticAccessAssignments,
invisible to search) — and if it is inheritable the two facts do not sit together. This does not
change what the fix does or that it is correct, but the exact production trigger is not fully
reconstructed and someone with a shell on that portal could settle it in one
GetEffectivePermissions call.

Secondary defects — NOT fixed here, please file

AccessControlPipeline's fold has no Timeout. Correct as stated for a stall: a fold that
never emits parks Concat and the delivery is dropped with no DeliveryFailure and no log line.
Left out on purpose — the file carries an explicit, argued "No Timeout here" decision, the
cold-start silence measured on DeleteNode pre-validate-descendants: 150 of 150 Release records of an orphan NodeType never answer ValidateDeleteRequest — the orphan cannot be deleted #3061 was per-node-hub ACTIVATION (upstream of this fold, so a gate
timeout would not have produced that message), and bounding it needs its own rung on the
MeshOperationOptions ladder plus a measurement of what actually stalls.
Correction to the brief: the empty-completion half is already covered —
CheckPermissionOutcome materialises the silent terminal as Undetermined (A starved permission fold parks every [RequiresPermission] delivery until the caller's own timeout — AccessControlPipeline has no terminal, and the bounded twin attributes the same event correctly #2742), so
DefaultIfEmpty() here can only mean "every check was granted".
PreValidateDescendantsObs bounds an O(N) cold fan-out with ONE stage budget. Real, and the
fix is a per-descendant rung, not a bigger number — a design change with the A recursive delete's commit stage can stall for its whole budget — pre-flight fan-out and budget nesting are fixed and deployed; the commit stall is unmeasured on memex-cloud #1198 ladder
invariant at stake.
HandleValidateDeleteRequest puts NestedTimeout on the storage read only;
RunDeletionValidatorsObs runs unbounded. Also real, and also a ladder decision: rung 2 is
already spent on the read and rung 3 is RlsNodeValidator's own budget, so bounding the validator
chain needs a new rung — equal budgets are exactly the "inner bound can never fire" defect
A recursive delete's commit stage can stall for its whole budget — pre-flight fan-out and budget nesting are fixed and deployed; the commit stall is unmeasured on memex-cloud #1198 exists to remove.
Stale doc claim (now corrected in this PR): AccessControl.md cited
DeleteHonoursNodeTypeAccessRuleTest at test/MeshWeaver.Security.Test, a path that does not
exist in this repo. The test is real but lives in MeshWeaver.Plugins
(src/MeshWeaver.Security.Test); the reference now says so.

🤖 Generated with Claude Code

https://claude.ai/code/session_01PPe8CH4mFU9E74HafWppqL

`ValidateDeleteRequest` carries `[RequiresPermission(Permission.Delete)]`, and `AccessControlPipeline` evaluated it through `GetPermissionChecks`, whose default implementation yields a RAW `(hubPath, Permission)` pair. It never consulted `INodeTypeAccessRule` — while `SatelliteAccessRule`, registered by `ActivityNodeType` and every other satellite type, maps a satellite's Delete to `Permission.Update` on its `MainNode`. #2913 reconciled exactly that mismatch in the delete PRE-FLIGHT (`MeshExtensions.CheckDeletePermissionForNode`) and not in the delivery gate, which runs FIRST — so the gate won. Measured on memex.systemorph.com: a recursive delete of the orphan NodeType `Edu/Course` refused with "Access denied: user 'rbuergi' lacks Delete permission on 'Edu/Course/_Activity/compile-…'" for all 72 of its `_Activity` satellites, so the one repair for a dangling NodeType was unavailable through any API. One shared seam so the two cannot drift again: `NodeTypeAccessRuleGate` owns resolution AND evaluation — the three terminals (verdict / fault / completed-without-emitting), the `TakeDecisionOutsideGate` hop, and the "the caller-visible detail names the exception TYPE, never its message" rule. The pre-flight, which used to write the evaluation out inline, now calls it; so does the gate. In the gate the rule is reached ONLY from a definitive denial: a grant is delivered untouched (a hot SubscribeRequest reads no node) and an Undetermined fold stays Undetermined ("we could not check" is not a rule question). Four conditions leave the denial exactly as it was — the check is not on this hub's own path, the permission names no operation a rule can decide about that node (`Permission.Create` maps to none: a create's subject does not exist yet and the gate sits on the PARENT's path), nothing is served at that path, or no rule governs. A node read that FAULTS answers Undetermined rather than the original denial, so a transient storage fault cannot silently restore the pre-fix behaviour. `SatelliteDeliveryGateTest` pins the three verdicts on one mesh: the Editor's satellite pre-flight is served, a Viewer's is still refused Unauthorized (the rule DENIES), and the same Editor at a plain Markdown child is still refused (no rule, nothing widened). Reverting `AccessControlPipeline.cs` alone reproduces the production message verbatim. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PPe8CH4mFU9E74HafWppqL

Copilot

🔵 Needs a closer look

It changes a core authorization gate (AccessControlPipeline) behavior in a security-sensitive path, so it warrants final human review despite strong test coverage.

Pull request overview

This PR fixes a mismatch between the message-delivery access gate (AccessControlPipeline) and node-type-specific access rules (INodeTypeAccessRule): when a [RequiresPermission] check is denied on a node whose type declares a governing access rule (e.g., satellites like _Activity/*), the gate now re-decides using that rule (aligning delivery-time gating with delete pre-flight behavior).

Changes:

Introduces NodeTypeAccessRuleGate as the shared implementation for (permission→operation) mapping, rule lookup, rule evaluation (including the three terminals), and served-node resolution.
Updates AccessControlPipeline to reconsider definitive denials via the node type’s rule (without affecting granted/undetermined outcomes).
Adds a regression test plus doc + What’s New updates to pin and explain the behavior.

File summaries

File	Description
test/MeshWeaver.Graph.Test/SatelliteDeliveryGateTest.cs	Adds a focused regression test pinning the three verdicts that distinguish “consult the rule” from “widen Delete”.
src/MeshWeaver.Mesh.Contract/Services/NodeTypeAccessRuleGate.cs	New shared seam for rule lookup + evaluation + subject-node reading, to prevent drift between delivery gate and delete pre-flight.
src/MeshWeaver.Mesh.Contract/MeshExtensions.cs	Routes delete pre-flight rule resolution/evaluation through `NodeTypeAccessRuleGate` to keep seams aligned.
src/MeshWeaver.Hosting/Security/AccessControlPipeline.cs	Re-decides denied `[RequiresPermission]` checks through the node type’s access rule when applicable.
src/MeshWeaver.Documentation/Data/WhatsNew/2026-09-02-deleting-a-node-takes-its-bookkeeping-with-it.md	Adds a user-facing “Fix” entry describing the behavioral correction at a high level.
src/MeshWeaver.Documentation/Data/Architecture/AccessControl.md	Updates the access-control architecture doc to reflect and justify the delivery-gate change (and its boundaries).

Review details

Files reviewed: 6/6 changed files
Comments generated: 0
Review effort level: Lite

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

github-actions · 2026-09-02T11:01:43Z