auth.users RLS enabled with zero policies — platform-wide login outage (ticket SU-542762)

[muhammad-ferdous-rahman]

We have an open Pro-plan support ticket (SU-542762) for a critical bug: on project syftmgiwgxbcmfufrfhy, auth.users, auth.identities and auth.sessions have Row Level Security enabled with zero policies, and supabase_auth_admin lacks BYPASSRLS. This blocks all new logins platform-wide — password, PIN, invite, magic link — not just an admin feature. We audited our own migration history and confirmed we never touched the auth schema, so this looks like a platform-side state issue. It's currently blocking two live customer pilot onboardings. Posting here for visibility alongside the ticket, as suggested in Supabase's own reply. Any help getting this looked at would be appreciated — thank you.

Happy to take follow-up by email too: ferdous@sentrylinkcomply.com

[SudoKMaar]

The RLS part of this is almost certainly a red herring, which matters because it points support at the wrong thing.

auth.users, auth.identities, auth.sessions (and every other auth table) having RLS enabled with zero policies is the stock state of every Supabase project. GoTrue's own migration does it: https://github.com/supabase/auth/blob/master/migrations/20240612123726_enable_rls_update_grants.up.sql (June 2024, alter table auth.users enable row level security and friends, no policies). And supabase_auth_admin not having BYPASSRLS is also normal, the role is created as CREATE USER supabase_auth_admin NOINHERIT CREATEROLE LOGIN NOREPLICATION (https://github.com/supabase/postgres/blob/develop/migrations/db/init-scripts/00000000000001-auth-schema.sql).

It works anyway because supabase_auth_admin owns those tables (same init script, ALTER table "auth".users OWNER TO supabase_auth_admin), and in Postgres the table owner bypasses RLS unless the table has FORCE ROW LEVEL SECURITY set: https://www.postgresql.org/docs/current/ddl-rowsecurity.html ("Table owners normally bypass row security as well, though a table owner can choose to be subject to row security with ALTER TABLE ... FORCE ROW LEVEL SECURITY").

So there are exactly two ways RLS could actually be blocking GoTrue on your project, and one query in the SQL editor tells you whether either is true:

select c.relname,
       c.relrowsecurity      as rls_enabled,
       c.relforcerowsecurity as rls_forced,
       pg_get_userbyid(c.relowner) as owner
from pg_class c
where c.relnamespace = 'auth'::regnamespace
  and c.relkind = 'r'
order by 1;

Healthy project: rls_enabled = t, rls_forced = f, owner = supabase_auth_admin on every row. If you see rls_forced = t anywhere, or an owner that is not supabase_auth_admin (typically postgres after some tool "fixed" ownership), that is your outage, and it is also the one-line fix support needs to run, since postgres cannot alter tables it does not own.

If that query comes back clean, RLS is not what is failing your logins and the ticket should move on. In that case the actual error is in the Auth logs (Dashboard, Logs, Auth), not in the client: GoTrue surfaces the real SQL error there (Database error querying schema, Database error granting user, permission denied on some table, etc.). The two things that usually break all login methods at once are a trigger on auth.users whose function fails or lacks security definer, and a failing Auth hook. Posting that log line here would get you a much faster answer than the RLS theory.

[muhammad-ferdous-rahman]

Hi, Following up on ticket SU-542762 — we found the actual root cause, and you were right that RLS wasn’t it. Thank you for pointing us toward the Auth logs instead; that’s exactly what cracked it. The real cause: our database had banned_until = 'infinity'::timestamptz set on 30 rows in auth.users (used as a “permanently banned” sentinel by one of our own functions). Postgres handles that value fine, but Supabase Auth’s Go service can’t scan the special infinity timestamp into a Go time.Time. Any admin.listUsers() call that paged through one of those rows crashed with "Database error finding users" — which is exactly the error we’d been chasing. We’ve since: Updated those rows to a safe, far-future timestamp instead of infinity Fixed the function that was creating them, so it can’t recur Confirmed admin.listUsers() now returns correctly So this was on our side, not a platform issue. Appreciate the help narrowing it down — closing this out on our end. Thanks again for the quick, clear response. Best, Ferdous

…

On 2026-11-08 01:27 PM, Abhishek Kumar wrote: The RLS part of this is almost certainly a red herring, which matters because it points support at the wrong thing. auth.users, auth.identities, auth.sessions (and every other auth table) having RLS enabled with zero policies is the stock state of every Supabase project. GoTrue's own migration does it: https://github.com/supabase/auth/blob/master/migrations/20240612123726_enable_rls_update_grants.up.sql (June 2024, alter table auth.users enable row level security and friends, no policies). And supabase_auth_admin not having BYPASSRLS is also normal, the role is created as CREATE USER supabase_auth_admin NOINHERIT CREATEROLE LOGIN NOREPLICATION (https://github.com/supabase/postgres/blob/develop/migrations/db/init-scripts/00000000000001-auth-schema.sql). It works anyway because supabase_auth_admin _owns_ those tables (same init script, ALTER table "auth".users OWNER TO supabase_auth_admin), and in Postgres the table owner bypasses RLS unless the table has FORCE ROW LEVEL SECURITY set: https://www.postgresql.org/docs/current/ddl-rowsecurity.html ("Table owners normally bypass row security as well, though a table owner can choose to be subject to row security with ALTER TABLE ... FORCE ROW LEVEL SECURITY"). So there are exactly two ways RLS could actually be blocking GoTrue on your project, and one query in the SQL editor tells you whether either is true: select c.relname, c.relrowsecurity as rls_enabled, c.relforcerowsecurity as rls_forced, pg_get_userbyid(c.relowner) as owner from pg_class c where c.relnamespace = 'auth'::regnamespace and c.relkind = 'r' order by 1; Healthy project: rls_enabled = t, rls_forced = f, owner = supabase_auth_admin on every row. If you see rls_forced = t anywhere, or an owner that is not supabase_auth_admin (typically postgres after some tool "fixed" ownership), that is your outage, and it is also the one-line fix support needs to run, since postgres cannot alter tables it does not own. If that query comes back clean, RLS is not what is failing your logins and the ticket should move on. In that case the actual error is in the Auth logs (Dashboard, Logs, Auth), not in the client: GoTrue surfaces the real SQL error there (Database error querying schema, Database error granting user, permission denied on some table, etc.). The two things that usually break _all_ login methods at once are a trigger on auth.users whose function fails or lacks security definer, and a failing Auth hook. Posting that log line here would get you a much faster answer than the RLS theory. -- Reply to this email directly, view it on GitHub [1], or unsubscribe [2]. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS [3] and Android [4]. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***> Links: ------ [1] #53118?email_source=notifications&email_token=B45Y5TSBXI3663CXMPXLMJ35YAN5BA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJUGY4TMOBWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-19469686 [2] https://github.com/notifications/unsubscribe-auth/B45Y5TR26OCQCMTX53B3RQD5YAN5BAVCNFSNUABIKJSXA33TNF2G64TZHMZDCNBVHA3TCOJTHNCGS43DOVZXG2LPNY5TCMJSGU2DIMRUUF3AE [3] https://github.com/notifications/mobile/ios/B45Y5TUHQIJKSN4EL65YOYL5YAN5BA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJUGY4TMOBWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM [4] https://github.com/notifications/mobile/android/B45Y5TXUOE4XTYFRVIJDF335YAN5BA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCOJUGY4TMOBWUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE

-- Muhammad Ferdous Rahman Founder & CEO | SentryLink Comply Management Consultant (RMG)| Digital Compliance & Traceability +8801713121344 ***@***.*** sentrylinkcomply.com ©2026 SentryLink Comply. All Rights Reserved.