How should PUBLIC EXECUTE on unaccent functions owned by supabase_admin be handled on hosted Supabase?

[coors222]

Hi,

I'm looking for clarification about the expected security model for extension functions owned by supabase_admin on hosted Supabase.

This appears very similar to discussion #49421 concerning pg_net, but in our case the extension is unaccent.

Environment

Hosted Supabase project running PostgreSQL 17.

The unaccent extension is installed in the extensions schema.

These functions are owned by supabase_admin:

extensions.unaccent(text)
extensions.unaccent(regdictionary, text)

Their ACL is:

{=X/supabase_admin,supabase_admin=X/supabase_admin,postgres=X*/supabase_admin}

Therefore PUBLIC has EXECUTE granted by supabase_admin, which means anon, authenticated, and service_role effectively have EXECUTE as members of PUBLIC.

Attempted REVOKE

A migration executed as postgres contained:

REVOKE ALL ON FUNCTION extensions.unaccent(text)
FROM PUBLIC, anon, authenticated, service_role;

REVOKE ALL ON FUNCTION extensions.unaccent(regdictionary, text)
FROM PUBLIC, anon, authenticated, service_role;

The migration completed, but the PUBLIC grant remained.

Our catalog checks show:

current_user = postgres
session_user = postgres
current_role = postgres

postgres member of supabase_admin = false
postgres can SET ROLE supabase_admin = false

So this appears to be the same ownership limitation described in #49421: postgres cannot revoke a privilege originally granted by the internal supabase_admin owner.

Data API exposure

Our PostgREST configuration is:

db_schema = public,graphql_public
db_extra_search_path = public,extensions

Therefore extensions is in the extra search path but is NOT one of the exposed Data API schemas.

We have not attempted to change ownership, role memberships, or gain access to supabase_admin.

Questions

1. Is PUBLIC EXECUTE on extensions.unaccent(...) intentional/expected on hosted Supabase?

2. Does the answer given in How can a project owner revoke PUBLIC privileges on the `net` schema (pg_net)? #49421 for pg_net also apply to unaccent — i.e. because extensions is not an exposed PostgREST schema, should we leave the extension's default ACL untouched?

3. Is keeping extensions outside db_schema the intended security boundary for Supabase-managed extension functions?

4. Is there any supported self-service method for a project owner to revoke a PUBLIC grant created by supabase_admin, or should these ACLs simply be treated as platform-managed?

5. Is there any realistic API bridge risk we should additionally guard against — for example, an executable function in public or graphql_public calling extensions.unaccent(...)?

6. Could an extension upgrade/reinstallation recreate these PUBLIC grants even if Supabase Support removed them?

Our goal is not to gain access to supabase_admin. We want to establish the correct, supported least-privilege invariant so that our Staging and Production migration procedures remain reproducible.

For now we have stopped subsequent migrations rather than attempting an unsupported ACL workaround.

Thanks.

[edwardsong08]

The linked pg_net discussion appears to apply to unaccent as well: on hosted projects, the extension objects are owned by the internal supabase_admin role, so the postgres role cannot reliably revoke privileges that were granted by that owner. The warning and unchanged ACL are consistent with that ownership boundary.

The important distinction is that a PUBLIC EXECUTE grant is not automatically a Data API exposure. Since extensions is not in db_schema, PostgREST should reject direct REST or RPC access to those functions. I would still treat that as an exposure boundary, not as a reason to assume the ACL can be changed from a migration.

For the least-privilege check, I would:

• Keep extensions out of db_schema unless there is a specific reason to expose it.
• Avoid SECURITY DEFINER functions in public or graphql_public that call extensions.unaccent(...) without tightly restricting EXECUTE.
• Explicitly grant EXECUTE only to the application roles that need your own wrapper functions, rather than trying to rewrite the extension-owned ACL.
• Re-check the ACL after an extension upgrade or reinstall, since the platform may recreate extension objects.

I would not stop migrations over this alone, but I would ask Supabase Support to confirm whether the unaccent ACL is platform-managed and whether they consider it an expected default. If Support removes or changes it, verify the result again after the next extension lifecycle event.