Re: Converting contrib SQL functions to new style

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> 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.

The situation of interest is where you are trying to install an extension
into a schema that also contains malicious objects. We've managed to make
most of the commands you might use in an extension script secure against
that situation, and Noah wants to hold SQL-function creation to that same
standard.

My concern in this patch is rendering SQL functions safe against untrusted
search_path at *time of use*, which is really an independent security
concern.

If you're willing to assume there's nothing untrustworthy in your
search_path, then there's no issue and nothing to fix. Unfortunately,
that seems like a rather head-in-the-sand standpoint.

regards, tom lane