Re: Prevent object capture in CREATE/ALTER EXTENSION scripts

From: solai v <solai(dot)cdac(at)gmail(dot)com>
To: Osama Abdul Qader <osamaabdulqader(dot)cs(at)gmail(dot)com>
Cc: Jan Nidzwetzki <jan(at)planetscale(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Prevent object capture in CREATE/ALTER EXTENSION scripts
Date: 2026-09-22 04:13:31
Message-ID: CAF0whudNaPuQma+UfNu8gWPtd85W+aApe-kHJaRRus_7qs6ZYw@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi all,

I tested the latest patch series for preventing object capture in
CREATE/ALTER EXTENSION scripts.
First, I was able to reproduce the reported issue. With f(varchar)
owned by the trusted role and an attacker-owned f(text) in the same
schema, the call f('abc') from the extension script resolved to the
attacker-owned function and returned ATTACKER FUNCTION.
I then tested patch 0001 alone. The behavior was unchanged, and the
extension script still resolved the call to ATTACKER FUNCTION.
After applying both patches, I repeated the test with the varchar
function owned by a superuser and the text function owned by a
non-superuser. This time, the extension was created successfully and
the result was:
SELECT * FROM test_ext.capture_result;
TRUSTED FUNCTION
I also checked the normal function calls outside the extension script:
f('abc'::varchar) -> TRUSTED FUNCTION
f('abc'::text) -> ATTACKER FUNCTION
f('abc') ->ATTACKER FUNCTION
So the normal function resolution behavior remains unchanged.
The regression tests added by the patch also passed successfully:
Overall, the patch worked as expected in my testing. The extension
script now selects the trusted candidate instead of the attacker-owned
candidate when both overloads are present.

Regards,
solai

In response to

Browse pgsql-hackers by date

  From Date Subject
Previous Message Amit Kapila 2026-09-22 04:09:49 Re: Adding a range check on the sequence index from the publisher.