From: | Isaac Morland <isaac(dot)morland(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, 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 14:18:32 |
Message-ID: | CAMsGm5eaD06esdYFYdT15wJeGPSio29GjM0vd4vXss+Nw=zT-Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 8 August 2018 at 09:58, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
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.
>
>
I must be missing something. Aren't search_path manipulation problems
avoided by using "SET search_path FROM CURRENT"?
While I'm asking, does anybody know why this isn't the default, especially
for SECURITY DEFINER functions? It seems like in addition to being a more
secure default, it would be better for JIT compilation - right now it seems
you need to re-compile whenever the function is called with a different
search_path. The ability for a function's meaning to change dramatically
depending on the caller's search_path seems like an occasionally-useful
extra, not what one would expect as the default.
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2018-08-08 14:40:02 | Re: Temporary tables prevent autovacuum, leading to XID wraparound |
Previous Message | David Steele | 2018-08-08 14:08:49 | Re: Standby trying "restore_command" before local WAL |