| From: | Jan Nidzwetzki <jan(at)planetscale(dot)com> |
|---|---|
| To: | solai v <solai(dot)cdac(at)gmail(dot)com>, Osama Abdul Qader <osamaabdulqader(dot)cs(at)gmail(dot)com> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Prevent object capture in CREATE/ALTER EXTENSION scripts |
| Date: | 2026-09-22 14:59:10 |
| Message-ID: | 3f6db46e-3175-40de-9001-ccde3a8b05f2@planetscale.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi solai,
On 22.09.26 06:13, solai v wrote:
[...]
> 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.
Thank you so much for the review.
While testing the patch further, I found a gap with schema-qualified
names. In v1, the trust check for relations and types was applied only
when the script used an unqualified name and the lookup went through
RelnameGetRelid() or TypenameGetTypidExtended(). A reference such as
@extschema(at)(dot)foo took the qualified branch of RangeVarGetRelidExtended()
or LookupTypeNameExtended() and was not checked at all. Functions and
operators were not affected, since their candidate lookup handles both
versions in one place.
v2 adds the check to those two branches, so an untrusted match is
treated as nonexistent there too. I also added tests for this case; I
slightly adjusted the commit message and rebased the patch set against
master.
Best regards
Jan
--
Jan Nidzwetzki
PlanetScale Postgres Core Team
| Attachment | Content-Type | Size |
|---|---|---|
| v2-0001-Propagate-extension-script-state-to-parallel-work.patch | text/plain | 4.3 KB |
| v2-0002-Prefer-trusted-candidates-when-resolving-names-in.patch | text/plain | 83.5 KB |
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nikolay Samokhvalov | 2026-09-22 15:07:41 | Re: EXPLAIN: showing ReadStream / prefetch stats |
| Previous Message | Greg Burd | 2026-09-22 14:54:33 | Double content-lock acquisition silently leaks a lock |