0002_auth_users_exposed false positive: pg_depend join lacks a refclassid filter (cross-catalog OID collision)

Aperta Adatta ai principianti
  • Qualcosa non va?
#171 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@tushardev-365 ci sta già lavorando.

Dal 29/7/2026.

  • #174 di @tushardev-365 — aperta
  • #177 di @karpovantonme — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
78/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
postgres
Ambito
databases, security

Direzione di ricerca

Inizia in lints/0002_auth_users_exposed.sql e analizza la join di pg_depend descritta nell'issue. Usa la query diagnostica del report per riprodurre la collisione di OID tra cataloghi. Il lavoro è completato quando il lint non segnala più una view la cui dipendenza è solo un oggetto pg_proc, continuando però a rilevare una dipendenza da relazione su auth.users.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Summary

lints/0002_auth_users_exposed.sql joins the view's rewrite dependencies to auth.users by OID only:

join pg_catalog.pg_depend d
    on d.refobjid = auth_users_pg_class.oid

There is no d.refclassid = 'pg_catalog.pg_class'::regclass predicate, so any pg_depend row from a view's rewrite whose refobjid numerically collides with auth.users' pg_class OID — but actually references an object in a different catalog (pg_proc, pg_type, …) — fires the lint.

Observed instance

On one of our projects, auth.users has pg_class OID 16499, and a public view calls a SECURITY DEFINER helper function whose pg_proc OID is also 16499. The view selects only from public tables (verified: zero relation dependency on auth.users), yet the advisor reports it as CRITICAL auth_users_exposed, and the "action required: security vulnerabilities" email goes out weekly.

Diagnostic query that shows the collision:

with au as (
  select oid from pg_class
  where relname = 'users' and relnamespace = 'auth'::regnamespace
),
rw as (
  select oid from pg_rewrite where ev_class = 'public.<your_view>'::regclass
)
select d.refclassid::regclass as ref_catalog,
       case when d.refclassid = 'pg_proc'::regclass then d.refobjid::regprocedure::text
            when d.refclassid = 'pg_class'::regclass then d.refobjid::regclass::text
            else d.refobjid::text end as ref_object,
       d.deptype
from pg_depend d, au, rw
where d.objid = rw.oid and d.refobjid = au.oid;

Result on the affected project: one row, ref_catalog = pg_proc, ref_object = <helper function>(text,uuid) — not a relation.

Suggested fix

Add the catalog filter to the join:

join pg_catalog.pg_depend d
    on d.refobjid = auth_users_pg_class.oid
    and d.refclassid = 'pg_catalog.pg_class'::regclass

(Other OID-equality joins in the lint suite may want the same audit.)

Lingua principale
PLpgSQL
Stelle
284
Fork
110
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di supabase/splinter

Tutte le issue di supabase/splinter

Issue simili

Altre issue su Databases

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.