Re: Facility for detecting insecure object naming - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Facility for detecting insecure object naming
Date
Msg-id 12429.1533736718@sss.pgh.pa.us
Whole thread Raw
In response to Re: Facility for detecting insecure object naming  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: Facility for detecting insecure object naming
Re: Facility for detecting insecure object naming
Re: Facility for detecting insecure object naming
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> +1.  Better still would be to invent a way to remove the need for such
> onerous qualification, but I don't have a good idea.

Yeah.

> So I guess what we need is a UI that lets you say either:

> - Don't tell me about anything, or
> - Tell me about all unqualified references, or
> - Tell me about all unqualified references except those that latch
> onto an object in <list of schemas>

> Personally, I'm not entirely sold on having that third capability.  I
> guess it's valuable, but the second one seems like the much more
> valuable thing.

I'm not sold on #2 either.  That path leads to, for example,
s/=/OPERATOR(pg_catalog.=)/g everywhere, which is utterly catastrophic
to both readability and portability of your SQL code.  We *must* find
a way to do better, not tell people that's what to do.

When the security team was discussing this issue before, we speculated
about ideas like inventing a function trust mechanism, so that attacks
based on search path manipulations would fail even if they managed to
capture an operator reference.  I'd rather go down that path than
encourage people to do more schema qualification.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Typo in doc or wrong EXCLUDE implementation
Next
From: Tom Lane
Date:
Subject: Re: pgsql: Fix run-time partition pruning for appends with multiple source