0002_auth_users_exposed false positive: pg_depend join lacks a refclassid filter (cross-catalog OID collision)
Nobody has claimed this yet.
Assessment
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Newbie friendliness
- 78/100
Research direction
Start in lints/0002_auth_users_exposed.sql and inspect the pg_depend join described in the issue. Use the diagnostic query from the report to reproduce the cross-catalog OID collision. Done means the lint no longer reports a view whose dependency is only a pg_proc object, while still detecting a relation dependency on auth.users.
Written by the indexing model from the issue text.
Description
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.)
- Dominant language
- PLpgSQL
- Stars
- 275
- Forks
- 102
- Avg merge
- 2d 8h
- Merged PRs (30d)
- 3
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from supabase/splinter
-
Difficulty 4/5 3-5 days Newbie friendliness 68/100
-
Difficulty 4/5 3-5 days Newbie friendliness 45/100
-
documentation
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
Difficulty 5/5 Over a week Newbie friendliness 45/100
-
Bug Openbug
Difficulty 3/5 1-2 days Newbie friendliness 15/100
All issues in supabase/splinter
Similar issues
-
bug: AI Gateway client filter lists "Unknown" twice when NULL and literal Unknown clients coexist Openbug
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
-
[BUG] A column whose default is the empty string is drawn in the ER diagram as having no default Openbug database-provider good first issue hacktoberfest
Difficulty 2/5 1-3 hours Newbie friendliness 90/100
libredb/libredb-studio#1030 · 6 comments ·
-
comp-datalake
Difficulty 2/5 1-3 hours Newbie friendliness 88/100
ClickHouse/ClickHouse#121222 ·
-
bug
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
-
bug redshift
Difficulty 2/5 1-3 hours Newbie friendliness 88/100