| 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
| 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. |