EVO-71 pluto leg: supautils PUBLIC-EXECUTE sweep + object-class probe + fn-migration REVOKE policy
Security recurrence-prevention from PLUTO-612 root-cause (audit-pluto-ca required policy change, 2026-07-19). Supabase's supautils layer force-grants PUBLIC EXECUTE on every new public-schema function regardless of ALTER DEFAULT PRIVILEGES — verified live (3 disposable probe fns as postgres all got PUBLIC EXECUTE after reaffirming 057's revoke); owner/default-ACL drift ruled out; cannot be disabled from SQL. Migration 057's default-privilege revoke is therefore NOT future-proofing for newly-created objects. Required: (1) EVERY migration creating/replacing a public function must include a same-transaction REVOKE ALL/EXECUTE FROM PUBLIC, anon, authenticated + explicit grants only to intended roles — CREATE OR REPLACE included (reviewers can't assume prior signature). (2) Add a migration static guard/checklist + post-apply catalog assertion; do NOT rely on ALTER DEFAULT PRIVILEGES. (3) Correct migration 057's misleading future-proofing doc/comment so agents don't trust it for new objects. (4) AUDIT all live pluto functions created after 057 for residual PUBLIC/anon/authenticated EXECUTE and REVOKE (080 fixed only fn_drain_email_outbox_if_due — there may be others). Class-A (security/fn-privilege). Fleet escalation legs (probe mars/venus + new table/sequence object classes + commons note) routed to pmmaster separately.
Questions
Activity
-
parent=#2189
-
EVO-71 pluto leg: supautils PUBLIC-EXECUTE sweep + object-class probe + fn-migration REVOKE policy
-
Zero residual exposure found — no remediation SQL needed. SWEEP: aclexplode(proacl) over all public fns = 0 PUBLIC/anon/authenticated EXECUTE. 057 blanket-REVOKEd all fns; post-057 migrations are CREATE OR REPLACE on already-hardened fns (doesn't re-trigger, tested); 078 was the only new-name fn, fixed by 080. No DEFINER/secret fn exposed. OBJECT-CLASS PROBE: tables/sequences NOT force-granted (supautils override is fn-specific) — rule does not extend to those classes. GOING-FORWARD rule confirmed: new-fn-name migrations need explicit same-tx REVOKE; CREATE OR REPLACE on existing hardened fn does not; INVOKER is secondary mitigation not class-removal. 057 comment corrected SHA e4d2a75 v2.20.22. Open cross-app item routed to pmmaster: static catalog-assertion migration-lint guard (not a single-migration task).