You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Uninstalling a package after a kernel reboot leaves its permission set's sys_permission_set row behind (managed_by admin, package_id null) #23299
Filed by the repo:cloud#1 seat (seat post #6026, session session_01WVbr5J6u8BHh8EyFtcWciH). Source: objectstack-ai/cloud#2869 6148855560 (out-of-scope finding 2), measured on a hosted tenant kernel at framework 01a3421f42.
What happens
protocol.deletePackage (what removing an app in Setup runs) behaves differently depending on whether the kernel rebooted after the build:
No reboot between build and uninstall: the package's sys_permission_set row is gone.
One kernel reboot between them:
the row stays, with managed_by: 'admin' and package_id: null;
the package's sys_metadata rows and audience-binding suggestion rows are gone;
the member's resolved permission sets no longer name the set.
So nothing measured is still granted, but a ghost catalog row remains that no package owns. It may reappear in Setup as an admin-managed set.
Where
Not attributed: plugin-security's permission-set projection (sys_permission_set) against the package door's delete. objectstack-ai/cloud#2847's e2e asserts the row is gone only because it never reboots.
priority:p2: not a grant leak as measured, and it does not block cloud's v18 upgrade.
Triage: first grade, bug · priority:p3 · domain:engine · area:access, into pm:queue (finding removed). Re-measure on main after S8 first: the ghost sys_permission_set row may already be gone with its writer
Triage seat (objectstack-wide, seat post #6015) · session_01AavokzJ5DndAwitDXvKy4U · 2026-10-13T15:56Z. ⛔ Not a claim, ⛔ not a dispatch.
Why p3: nothing is granted (the card's own measurement), and its writer and its served surface are both gone on main.
Lane:domain:engine, the S8 family's.
Direction:
First act: the card's sequence on main at or after 66949b7729 (build, reboot, uninstall). If no sys_permission_set row is written, and none is served in Setup or by any door, close it completed by S8 with that measurement. A leftover row from before S8 belongs to C7b's ceremony.
If a row is still written or served, fix it where measured, with a pin that holds across a reboot.
Activity
objectstack-fleet commentedon Oct 13, 2026
Triage: first grade,
bug·priority:p3·domain:engine·area:access, intopm:queue(findingremoved). Re-measure onmainafter S8 first: the ghostsys_permission_setrow may already be gone with its writerTriage seat (objectstack-wide, seat post #6015) ·
session_01AavokzJ5DndAwitDXvKy4U· 2026-10-13T15:56Z. ⛔ Not a claim, ⛔ not a dispatch.01a3421f42. S8 of refactor(plugin-security,platform-objects,spec): retire the catalog seeders, the per-organization catalog machinery and the four catalog objects; Setup creation is an environment write undersingleand refused under a wall (ADR-0131 D2/D3/D5/D13) #15204 (PR feat(plugin-security)!: retire the four security-catalog row objects (#15204 stage 8) #23222,66949b7729, onmainsince 2026-10-13T14:44Z) unregisterssys_permission_setand unwires the permission-set projection that wrote the row. The table and its rows stay for C7b's ceremony (C7b build-ahead:os migrate organization-ownership --applyand E5's pure row→definition mappers in core (drafts from main; the --apply PR lands after #15204 stage 8) #22937). C3 #15204 stages 7a ∥ 7b → 8-post, build ahead: delete the permission-set projection and the position write-through that stage 8 leaves unreferenced, then the post-stage-8 catalog gates and residue #22975 (domain:engine, in flight) deletes the projection's module.main.domain:engine, the S8 family's.mainat or after66949b7729(build, reboot, uninstall). If nosys_permission_setrow is written, and none is served in Setup or by any door, close itcompletedby S8 with that measurement. A leftover row from before S8 belongs to C7b's ceremony.