On Sun, Aug 5, 2018 at 1:34 PM, Noah Misch <noah@leadboat.com> wrote:
> If hackers and non-core extension authors are to write such code, let's make
> it easier to check the work.
+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.
> a. SQL intended to run under secure search_path. No class-specific rules.
> src/bin code is an example of this class, and this is the only secure class
> for end-user applications.
>
> b. SQL intended for a particular search_path, possibly untrusted. Unqualified
> names need an exact match. Use a qualified name for any object whose
> schema appears in search_path later than some untrusted schema. Examples
> of this class include extension scripts, pre-CVE-2018-1058 pg_dump, some
> functions with "SET search_path", and many casual end-user applications.
>
> c. SQL intended to work the same under every search_path setting. Do not use
> any unqualified name. Most pg_catalog and contrib functions, but not those
> having a "SET search_path" annotation, are examples of this class.
If I understand correctly, the only difference between (b) and (c) is
that references to an object in the very first schema in the search
path could be unqualified; in most cases, that would be pg_catalog.
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company