Repository navigation
Follow-ups from the security review of #59 (module page roles) #60
Description
From the independent security review of #59 (a module that declares a page declares roles); none blocks the merge, each fails closed.
- Old role grants come back across mode switches: generation 1 declares roles and an admin grants
viewer; generation 2 drops the roles; generation 3 redefinesvieweras read+write and the old holder gets the wider role with no admin action.Narrowed(decide/manifest.go:126) notices roles being cut, not widened (solutions share the gap); and admins cannot see a module's role definitions because review refuses anything that is not a solution (consent.go:104). - Switching a module to roles locks every member of every organisation out: installations made at delivery carry no installer grant (lifecycle.go:109-125); access returns only once an org admin grants roles. Decide whether delivery should seed the organisation's admins as installers of a module page, or the host should prompt.
- Role scopes on kinds the module only consumes are accepted but do nothing (manifest.go:73-74 lets them through; issue.go:56 cuts held scopes to what the module serves). Refuse them or document it.
Findings 1 (ListResources at a module page answered from org roles) and 5 (conformance case did not show org roles applying again) were fixed on #59 before merge.
🤖 Generated with Claude Code
Activity
antoinetoussaint-byte commentedon Oct 30, 2026
From the review of module-saas-starter#1282: a redelivery keeps the grants of a role the module dropped; if the roles are later re-added, earlier holders get access back (solutions too). Same family as item 1 here.
antoinetoussaint-byte commentedon Oct 30, 2026
From the review of #62 (merge, no blocker): (a) review (consent.go:86) reads the core's own id first and accepts a tombstoned record while issuance prefers the active installation: look module pages up by target on hosts that install modules, consistently; (b) an empty organisation matches every organisation in the in-memory store (memstore.go:320): reject an empty organisation before the lookup; (c) several active installations for one target do not fail closed (first in store order wins).