From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Subject: | Re: Converting contrib SQL functions to new style |
Date: | 2021-04-14 13:55:56 |
Message-ID: | CA+TgmoaF_DKSPRnbkakkOufWMFpOBsA8fwE-mF0fF7aeH20zqg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Apr 14, 2021 at 8:58 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
> Once CREATE EXTENSION is over, things are a great deal safer under this
> proposal, as you say. I suspect it makes CREATE EXTENSION more hazardous.
> Today, typical SQL commands in extension creation scripts don't activate
> inexact argument type matching. You were careful to make each script clear
> the search_path around commands deviating from that (commit 7eeb1d9). I think
> "CREATE FUNCTION plus1dot1(int) RETURNS numeric LANGUAGE SQL RETURN $1 + 1.1;"
> in a trusted extension script would constitute a security vulnerability, since
> it can lock in the wrong operator.
I don't understand how that can happen, unless we've failed to secure
the search_path. And, if we've failed to secure the search_path, I
think we are in a lot of trouble no matter what else we do.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Bharath Rupireddy | 2021-04-14 14:06:06 | Can a child process detect postmaster death when in pg_usleep? |
Previous Message | Robert Haas | 2021-04-14 13:49:09 | Re: sepgsql logging |