On Sun, Aug 5, 2018 at 1:34 PM, Noah Misch <n...@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
