Re: Avoid leaking system path from pg_available_extensions

From: Chao Li <li(dot)evan(dot)chao(at)gmail(dot)com>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: Matheus Alcantara <matheusssilv97(at)gmail(dot)com>, Jim Jones <jim(dot)jones(at)uni-muenster(dot)de>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Avoid leaking system path from pg_available_extensions
Date: 2026-05-31 04:26:51
Message-ID: 9ABAF640-2E1D-4825-8C0D-D2FF95BBD236@gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> On May 30, 2026, at 21:21, Andrew Dunstan <andrew(at)dunslane(dot)net> wrote:
>
>
> On 2026-05-26 Tu 9:29 AM, Matheus Alcantara wrote:
>> On 26/05/26 04:14, Chao Li wrote:
>>>
>>>
>>>> On May 22, 2026, at 23:40, Matheus Alcantara <matheusssilv97(at)gmail(dot)com> wrote:
>>>>
>>>> On 22/05/26 04:25, Jim Jones wrote:
>>>>> On 21/05/2026 17:12, Matheus Alcantara wrote:
>>>>>> I've reproduced the issue and the fix looks correct to me.
>>>>> same here, +1
>>>>
>>>> Thank you for also testing.
>>>>
>>>>> I was wondering if creating a constant for it would be, stylistically
>>>>> speaking, a cleaner solution. For instance:
>>>>> #define EXTENSION_SYSTEM_MACRO "$system"
>>>>> I realize that it's used only inside get_extension_control_directories()
>>>>> but since it is even mentioned in the docs, I guess it wouldn't be a bad
>>>>> idea.
>>>>
>>>> I'm not against it but I don't think that it's necessary since as you mention, only get_extension_control_directories() use.
>>>>
>>>
>>> In theory, I’m not against the idea either. In practice, there are many hard-coded strings in the source tree, and I’m not sure where the right place would be to define this macro.
>>>
>>> Since this string is only used in get_extension_control_directories(), and now it is used three times, I defined it at the beginning of the function and undefined it at the end. Let’s see if there are any objections to that.
>>>
>>> Please see the attached v2.
>>>
>>
>> We have such pattern in other parts of the codebase (e.g pg_resetwal.c), so it works for me.
>>
>> Thanks for the patch.
>>
>>
>
> Pushed.
>
>
> cheers
>
>
> andrew
>
> --
> Andrew Dunstan
> EDB: https://www.enterprisedb.com

Thanks for pushing.

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Ewan Young 2026-05-31 04:36:45 autovacuum launcher crash: assert in pgstat_count_io_op (IOOP_EXTEND on pg_database's VM)
Previous Message Chao Li 2026-05-31 01:57:06 Reject HEADER with binary and json COPY formats by option presence