Revoke default PUBLIC EXECUTE on SECURITY DEFINER functions

[tmablunar]

Summary

• PostgreSQL grants EXECUTE to PUBLIC by default on every new function. For CustomRole-managed SECURITY DEFINER functions (which typically run as an elevated owner like rds_superuser or rds_pgaudit), this meant any role on the cluster could invoke them — only the internal predicate checks (if any) stood between an arbitrary caller and the elevated action.
• Emit REVOKE ALL ON FUNCTION ... FROM PUBLIC as the function owner before the existing GRANT EXECUTE TO <roleName> so only the owning CustomRole (and roles granted membership in it) can call the function.
• The REVOKE runs via execWithRole like the surrounding DDL and is idempotent, so re-syncs stay consistent.

Test plan

• go build ./... and go vet ./pkg/postgres/...
• POSTGRESQL_CONTROLLER_INTEGRATION_HOST=localhost:5432 go test ./pkg/postgres/ (full package, all pass)
• New integration test TestSyncDatabaseFunctions_revokesPublicExecute asserts PUBLIC has no EXECUTE after sync while the target role still does
• CI green

🤖 Generated with Claude Code

---

Note

Medium Risk
Touches database privilege/ACL logic for SECURITY DEFINER functions; a mistake could break callers or unintentionally change access, though the change is narrowly scoped and covered by a new integration test.

Overview
SyncDatabaseFunctions now runs REVOKE ALL ON FUNCTION ... FROM PUBLIC (as the function owner) after ensuring ownership, removing PostgreSQL’s default PUBLIC EXECUTE grant on newly created SECURITY DEFINER functions before re-granting EXECUTE to the managed custom role.

Adds an integration test asserting the target role retains EXECUTE while PUBLIC does not, including a helper that correctly detects implicit default ACLs when proacl is NULL.

^{Reviewed by Cursor Bugbot for commit aeb9125. Configure here.}