Re: Facility for detecting insecure object naming

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

In response to

Responses

Browse pgsql-hackers by date

  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