Message-ID: <a35ef296-9438-2194-9c6c-807b2f174b0c@joeconway.com>
Date: Mon, 31 Jul 2023 13:17:59 -0400
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.13.0
Subject: Re: pgsql: Fix search_path to a safe value during maintenance
 operations.
To: Robert Haas <robertmhaas@gmail.com>, Jeff Davis <pgsql@j-davis.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Noah Misch <noah@leadboat.com>,
 "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>,
 Nathan Bossart <nathandbossart@gmail.com>
References: <E1q7j7Y-000z1H-Hr@gemulon.postgresql.org>
 <89a415b86d5421941e4281ba5bf6288934078624.camel@j-davis.com>
 <d20864b929ff769a0ebf772359719f05bb6982cd.camel@j-davis.com>
 <573014.1686375211@sss.pgh.pa.us> <20230612170510.GA201972@gust.leadboat.com>
 <f53df2dbe11bb42764bcdd003a54aa29c9bb6137.camel@j-davis.com>
 <20230613182920.GA259321@gust.leadboat.com>
 <1799839.1686687804@sss.pgh.pa.us>
 <4df537f5a0d8c0ceac3eec3809d1144880b8e76d.camel@j-davis.com>
 <CA+TgmoYtJU0KknWr11W--wK=4eJtdHOgupyT=beZVPC8P=o+YA@mail.gmail.com>
 <578fb4be80247570e6a05924908765a0b345971e.camel@j-davis.com>
 <CA+TgmoZVCHERUkXhAMT2Er-sKBc5C6_iX+TpxxivBevDHzq2TQ@mail.gmail.com>
 <43bbc9f7318057f51552d5986830908cb018dadf.camel@j-davis.com>
 <1659699.1688086436@sss.pgh.pa.us>
 <fff566293c9165c69bb4c555da1ac02c63660664.camel@j-davis.com>
 <CA+Tgmoa5mksH1rAggYYwm0fJAO8TCnLG_oRE=su06XfqU+KTLA@mail.gmail.com>
Content-Language: en-US
From: Joe Conway <mail@joeconway.com>
In-Reply-To: 
 <CA+Tgmoa5mksH1rAggYYwm0fJAO8TCnLG_oRE=su06XfqU+KTLA@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: 
 <https://www.postgresql.org/message-id/a35ef296-9438-2194-9c6c-807b2f174b0c%40joeconway.com>
Precedence: bulk

On 7/31/23 12:53, Robert Haas wrote:
> On Fri, Jun 30, 2023 at 3:41 AM Jeff Davis <pgsql@j-davis.com> wrote:
>> I'm not sure that everyone in this thread realizes just how broken it
>> is to depend on search_path in a functional index at all. And doubly so
>> if it depends on a schema other than pg_catalog in the search_path.
>>
>> Let's also not forget that logical replication always uses
>> search_path=pg_catalog, so if you depend on a different search_path for
>> any function attached to the table (not just functional indexes, also
>> functions inside expressions or trigger functions), then those are
>> already broken in version 15. And if a superuser is executing
>> maintenance commands, there's little reason to think they'll have the
>> same search path as the user that created the table.
>>
>> At some point in the very near future (though I realize that point may
>> come after version 16), we need to lock down the search path in a lot
>> of cases (not just maintenance commands), and I don't see any way
>> around that.
> 
> I agree. I think there are actually two interrelated problems here.
> 
> One is that virtually all code needs to run with the originally
> intended search_path rather than some search_path chosen at another
> time and maybe by a different user. If not, it's going to break, or
> compromise security, depending on the situation. The other is that
> running arbitrary code written by somebody else as yourself is
> basically instant death, from a security perspective.

I agree too.

But the analysis of the issue needs to go one step further. Even if the 
search_path does not change from the originally intended one, a newly 
created function can shadow the intended one based on argument coercion 
rules.

-- 
Joe Conway
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com