fix(db): anon could execute as a superuser, and a rebuild would restore that

[POWERFULMOVES]

Closes the anon question the review was parked on. It was answerable from RLS, not from the env — which is why chasing SUPABASE_KEY around the fleet never settled it.

The exposure

claim_ / complete_ / fail_studio_board_publish are SECURITY DEFINER, owned by supabase_admin (rolsuper). They execute as a superuser and bypass RLS. PUBLIC and anon both held EXECUTE.

Nobody granted that. All three defining migrations contain zero GRANT statements — it's Supabase's stock default privilege on public.

The schema already said the opposite

publisher_audit_svc        service_role   USING true   WITH CHECK true
publisher_audit_auth_read  authenticated  read-only
publisher_audit_anon_deny  anon           USING false  WITH CHECK false

And detections / segments / emotions / studio_board: RLS enabled, zero anon policies.

So anon is explicitly denied everywhere it's named — while holding EXECUTE on three functions that write studio_board as a superuser.

Why no consumer breaks

This is what settled the key-class question. The publisher (services/publisher/publisher.py → services/common/supabase.py:20-44) does direct inserts into those RLS-protected tables. An anon-key client cannot do that at all. It must be service_role — which keeps its explicit grant. authenticated keeps its own.

Why a migration and not a one-off

I applied it by hand on B850 tonight. A volume reset re-grants it, because the grant is a default privilege, not an authored one. Same class as the other three node-local fixes this week.

PUBLIC is revoked for the same reason one level up: every role inherits PUBLIC, which is how juicefs_meta — a LOGIN role that pg_hba now admits from the tailnet (#2702) — ended up holding superuser-execution rights it was created specifically not to have.

Verified

Asserts its end state in both directions, so it can't silently over- or under-revoke:

• nothing in public reachable by anon or juicefs_meta
• nothing lost by service_role or authenticated

Idempotent — re-applied against the already-hardened B850 DB, both assertion blocks pass. Resulting ACL:

supabase_admin=X | postgres=X | authenticated=X | service_role=X

(no =X/ PUBLIC entry, no anon=X). All 13 supabase services healthy after.

🤖 Generated with Claude Code

https://claude.ai/code/session_01FkwiW3VY1xWmahTAtVioxz

[coderabbitai]

Important

• 🔍 Trigger review

This repository does not receive automatic reviews because it has fewer than 10 stars.

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 8ac1db46-7f8f-4dfa-81ba-17dc6e70b381

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 796ab890da

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[POWERFULMOVES]

Verified and fixed — you're right, and the failure mode is worse than an abort.

Confirmed the ordering at pmoves/Makefile:821-822: apply_dir migration supabase/migrations then apply_dir seed supabase/initdb, and 00_3_juicefs_meta_role.sql is a seed. The apply loop catches a failing file, prints FAILED (skipped) and continues without recording it in pmoves_bootstrap_history — so the bootstrap reports success and the hardening silently never applies, on exactly the rebuild path this migration exists to secure.

REVOKE has the same problem, so both halves are guarded: the revoke only names anon when it exists (created by bootstrap_db.sh, a different entrypoint that isn't ordered against supabase-bootstrap), and the assertion CONTINUEs past absent roles. The PUBLIC half stays unconditional — which is what preserves the guarantee, since revoking from PUBLIC removes what juicefs_meta would inherit whenever it's created.

Tested on a throwaway postgres:17 with neither role present: exits 0, PUBLIC revoked (postgres=X/postgres). Then a negative test — create anon, grant EXECUTE — and the assertion raises revoke incomplete: anon still holds EXECUTE on 1 secdef function(s), so it has teeth rather than passing vacuously.