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

Abierto Apto para principiantes
  • ¿Algo no está bien?
#171 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@tushardev-365 ya está trabajando en esto.

Desde el 29/7/2026.

  • #174 de @tushardev-365 — abierto
  • #177 de @karpovantonme — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
78/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Tranquilo
Stack tecnológico
postgres
Área
databases, security

Línea de trabajo

Empieza en lints/0002_auth_users_exposed.sql e inspecciona el join de pg_depend descrito en el issue. Usa la consulta de diagnóstico del informe para reproducir la colisión de OID entre catálogos. Se considera terminado cuando el lint ya no informa de una vista cuya dependencia sea únicamente un objeto pg_proc, pero siga detectando una dependencia de relación en auth.users.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.)

Lenguaje dominante
PLpgSQL
Estrellas
284
Forks
110
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de supabase/splinter

Todos los issues de supabase/splinter

Issues similares

Más issues de Databases

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.