Hosted Storage migration 0073: supported rollout and recovery for residual TRUNCATE grants

[maresbarreraadrian-code]

Hello Supabase team/community,

We are seeking an officially supported security assessment and recovery procedure for managed Storage privileges on hosted PostgreSQL 17. This is a guidance request, not a claim of a demonstrated exploit or authorization to change a project.

Read-only catalog inspection found six residual direct and effective TRUNCATE grants:

Managed object	Roles with TRUNCATE	Owner / grantor	API-role grant option
storage.buckets	anon, authenticated	supabase_storage_admin	No
storage.buckets_analytics	anon, authenticated	supabase_storage_admin	No
storage.objects	anon, authenticated	supabase_storage_admin	No

RLS is enabled on these objects. We have not performed destructive tests, changed managed privileges/owners or tried privilege escalation. These current-object grants are distinct from any future default privileges.

The official managed-schema restriction announcement includes revoking privileges from API roles in Storage among restricted client operations. We want to preserve supported service behavior, ownership and recovery.

We also reviewed the related community question and verified the merged official Storage PR 1395. Its tenant migration 0073 addresses these three tables, but also other privileges, defaults and vector-table permissions. We have not run that SQL ourselves. Our remaining question is the provider-supported hosted rollout and recovery path, not a workaround for managed ownership.

Could you please confirm:

1. What practical risk do these effective grants represent within the supported hosted access paths? Which additional conditions matter to the risk assessment?
2. For a hosted tenant where migration 0073 is not yet recorded, how should a customer verify rollout status and request its supported application? Is a provider-controlled change limited to these six grants available, or must the broader migration apply? Please distinguish current effective privileges from future default privileges.
3. Which privileges are required for managed Storage operations, analytics, maintenance and upgrades? Can an upgrade reinstate these grants?
4. Which changes may a customer perform without compromising support or compatibility, and which require provider-controlled authority?
5. What documented recovery restores the original ACLs, grantor and grant-option state if a supported correction regresses functionality? Please distinguish transaction rollback, post-commit ACL recovery and database/object-byte restoration.
6. Is there a safe supported mitigation or review path that requires no paid resource or plan upgrade, if removing the grants is not supported?

No private project/account identifiers, customer records, credentials, session data, object content or internal files are included. We request guidance only and will obtain separate approval before any managed change.

Thank you.

[cekuu35]

Adding the effective-risk layer to your (thorough) catalog work, because one fact in your post deserves a flag before anyone treats the enabled RLS as the mitigation: TRUNCATE is not subject to row-level security in Postgres. RLS filters SELECT/INSERT/UPDATE/DELETE — TRUNCATE bypasses it by design. So the residual TRUNCATE grants on storage.buckets/storage.objects/storage.buckets_analytics are not mitigated by the RLS you confirmed; they're only mitigated by whether the grant can actually be exercised.

Who can exercise these grants on hosted Supabase

1. PostgREST path: no. The REST layer exposes row-level operations; there is no TRUNCATE operation in the PostgREST surface. The anon/authenticated roles reach Postgres through PostgREST, and this vector doesn't exist there.
2. Realtime: no. Realtime reads WAL for change delivery; no DDL pathway.
3. Direct Postgres connections: effectively no, with one caveat. The anon/authenticated roles are JWT-substituted roles — they hold no passwords, so they can't log in directly. Direct connections use password-holding roles (postgres or custom LOGIN roles), which exercise their own grants, not these. The caveat: any custom SECURITY DEFINER function in your project (not the managed storage schema) that accepts a table name and issues dynamic SQL while granted to the API roles would be a bridge — a quick census for that class:

select p.proname, n.nspname, pg_get_userbyid(p.proowner) as owner
from pg_proc p
join pg_namespace n on n.oid = p.pronamespace
join pg_roles r on r.oid = p.proacl::regrole
where p.prosecdef and n.nspname = 'public'
  and exists (
    select 1 from aclexpansion(acl) -- or your preferred ACL expansion
  );

(The practical version: list your own SECURITY DEFINER functions in public and confirm none of them execute DDL from role-controllable input. In a stock project the set is small — auth triggers, handle_new_user and friends — and none do.)

4. Dashboard SQL editor: runs as postgres, which isn't gated by these grants at all.

So the effective exercise surface today is: none through the supported paths, gated only by future changes — which is exactly why you're right to want the provider-supported rollout rather than a workaround.

What migration 0073 changes (from the merged storage PR)

The tenant migration addresses precisely the three tables you listed (plus vector-permission and default-privilege cleanup). Two things worth noting for your recovery procedure:

• Rollout asymmetry: the platform applies managed migrations on its schedule; your project's effective grants may retain the residual state until the platform's rollout reaches your tenant — the catalog state you see today is legitimate to observe until then. Your read-only approach (inspect, don't touch) is the correct posture for staying supported.
• Recovery: the supported recovery for a mistaken manual change on managed objects has been "support ticket + platform-side reconciliation" (the managed-schema discussion you linked documents the restricted operations explicitly). There is no self-serve re-run for the tenant migration on hosted — by design.

The interim verification set

While waiting for the supported rollout, the checks that keep the file clean:

-- 1. Effective grants haven't grown (the census you already run)
select grantee, table_name, privilege_type
from information_schema.role_table_grants
where table_schema = 'storage'
  and grantee in ('anon', 'authenticated')
order by table_name, privilege_type;

-- 2. No SECURITY DEFINER bridge in your own schema (the class above)
select p.proname
from pg_proc p
join pg_namespace n on n.oid = p.pronamespace
where n.nspname = 'public' and p.prosecdef;

-- 3. Default privileges for future storage objects haven't drifted
select * from pg_default_acl where defaclnamespace = 'storage'::regnamespace::oid;

Baseline all three today, re-run after the platform announces the rollout — any drift between the two runs is your support-ticket evidence, which is a materially stronger artifact than a one-time snapshot.

For the credential-side hygiene questions that pair with this managed-surface audit (what the rotation path records where, and which channels can't guarantee redaction) — the adjacent threads have the channel-by-channel map: #51544 and #51499.