From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Noah Misch <noah(at)leadboat(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Facility for detecting insecure object naming |
Date: | 2018-08-08 13:58:38 |
Message-ID: | 12429.1533736718@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2018-08-08 14:04:12 | Re: pgsql: Fix run-time partition pruning for appends with multiple source |
Previous Message | Tom Lane | 2018-08-08 13:51:28 | Re: Typo in doc or wrong EXCLUDE implementation |