Horton

Thread

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Avoid leaking system path from pg_available_extensions

  1. Avoid leaking system path from pg_available_extensions

    Chao Li <li.evan.chao@gmail.com> — 2026-05-20T01:00:29Z

    Hi,

I just tested “Add paths of extensions to pg_available_extensions”, and found an issue.

This is a simple repro:
```
evantest=# reset extension_control_path;
RESET
evantest=# select * from pg_available_extensions where name = 'plpgsql';
  name   | default_version | installed_version | location |           comment
---------+-----------------+-------------------+----------+------------------------------
 plpgsql | 1.0             | 1.0               | $system  | PL/pgSQL procedural language
(1 row)

evantest=# set extension_control_path='';
SET
evantest=# select * from pg_available_extensions where name = 'plpgsql';
  name   | default_version | installed_version |             location             |           comment
---------+-----------------+-------------------+----------------------------------+------------------------------
 plpgsql | 1.0             | 1.0               | /usr/local/pgsql/share/extension | PL/pgSQL procedural language
(1 row)
```

When extension_control_path is not set, location shows “$system", which is consistent with what the documentation says:
```
       <para>
        The default value for this parameter is
        <literal>'$system'</literal>. If the value is set to an empty
        string, the default <literal>'$system'</literal> is also assumed.
       </para>
```

However, as shown above, when I set extension_control_path to an empty string, the absolute system path is displayed. I consider this an information leakage bug.

The fix is straightforward; see the attached patch for details. After the fix, when extension_control_path is an empty string, location shows “$system” now:
```
evantest=# set extension_control_path='';
SET
evantest=# select * from pg_available_extensions where name = 'plpgsql';
  name   | default_version | installed_version | location |           comment
---------+-----------------+-------------------+----------+------------------------------
 plpgsql | 1.0             | 1.0               | $system  | PL/pgSQL procedural language
(1 row)
```

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

  2. Re: Avoid leaking system path from pg_available_extensions

    Chao Li <li.evan.chao@gmail.com> — 2026-05-20T01:07:49Z

    
> On May 20, 2026, at 09:00, Chao Li <li.evan.chao@gmail.com> wrote:
> 
> Hi,
> 
> I just tested “Add paths of extensions to pg_available_extensions”, and found an issue.
> 
> This is a simple repro:
> ```
> evantest=# reset extension_control_path;
> RESET
> evantest=# select * from pg_available_extensions where name = 'plpgsql';
>  name   | default_version | installed_version | location |           comment
> ---------+-----------------+-------------------+----------+------------------------------
> plpgsql | 1.0             | 1.0               | $system  | PL/pgSQL procedural language
> (1 row)
> 
> evantest=# set extension_control_path='';
> SET
> evantest=# select * from pg_available_extensions where name = 'plpgsql';
>  name   | default_version | installed_version |             location             |           comment
> ---------+-----------------+-------------------+----------------------------------+------------------------------
> plpgsql | 1.0             | 1.0               | /usr/local/pgsql/share/extension | PL/pgSQL procedural language
> (1 row)
> ```
> 
> When extension_control_path is not set, location shows “$system", which is consistent with what the documentation says:
> ```
>       <para>
>        The default value for this parameter is
>        <literal>'$system'</literal>. If the value is set to an empty
>        string, the default <literal>'$system'</literal> is also assumed.
>       </para>
> ```
> 
> However, as shown above, when I set extension_control_path to an empty string, the absolute system path is displayed. I consider this an information leakage bug.
> 
> The fix is straightforward; see the attached patch for details. After the fix, when extension_control_path is an empty string, location shows “$system” now:
> ```
> evantest=# set extension_control_path='';
> SET
> evantest=# select * from pg_available_extensions where name = 'plpgsql';
>  name   | default_version | installed_version | location |           comment
> ---------+-----------------+-------------------+----------+------------------------------
> plpgsql | 1.0             | 1.0               | $system  | PL/pgSQL procedural language
> (1 row)
> ```
> 
> Best regards,
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
> 
> 
> 
> 

Oops, forgot the attachment. Here comes it.

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

  3. Re: Avoid leaking system path from pg_available_extensions

    lu feng <fnlo1995@gmail.com> — 2026-05-21T08:55:47Z

    Chao Li <li.evan.chao@gmail.com> 于2026年5月20日周三 09:08写道：

>
>
> > On May 20, 2026, at 09:00, Chao Li <li.evan.chao@gmail.com> wrote:
> >
> > Hi,
> >
> > I just tested “Add paths of extensions to pg_available_extensions”, and
> found an issue.
> >
> > This is a simple repro:
> > ```
> > evantest=# reset extension_control_path;
> > RESET
> > evantest=# select * from pg_available_extensions where name = 'plpgsql';
> >  name   | default_version | installed_version | location |
>  comment
> >
> ---------+-----------------+-------------------+----------+------------------------------
> > plpgsql | 1.0             | 1.0               | $system  | PL/pgSQL
> procedural language
> > (1 row)
> >
> > evantest=# set extension_control_path='';
> > SET
> > evantest=# select * from pg_available_extensions where name = 'plpgsql';
> >  name   | default_version | installed_version |             location
>          |           comment
> >
> ---------+-----------------+-------------------+----------------------------------+------------------------------
> > plpgsql | 1.0             | 1.0               |
> /usr/local/pgsql/share/extension | PL/pgSQL procedural language
> > (1 row)
> > ```
> >
> > When extension_control_path is not set, location shows “$system", which
> is consistent with what the documentation says:
> > ```
> >       <para>
> >        The default value for this parameter is
> >        <literal>'$system'</literal>. If the value is set to an empty
> >        string, the default <literal>'$system'</literal> is also assumed.
> >       </para>
> > ```
> >
> > However, as shown above, when I set extension_control_path to an empty
> string, the absolute system path is displayed. I consider this an
> information leakage bug.
> >
> > The fix is straightforward; see the attached patch for details. After
> the fix, when extension_control_path is an empty string, location shows
> “$system” now:
> > ```
> > evantest=# set extension_control_path='';
> > SET
> > evantest=# select * from pg_available_extensions where name = 'plpgsql';
> >  name   | default_version | installed_version | location |
>  comment
> >
> ---------+-----------------+-------------------+----------+------------------------------
> > plpgsql | 1.0             | 1.0               | $system  | PL/pgSQL
> procedural language
> > (1 row)
> > ```
> >
> > Best regards,
> > --
> > Chao Li (Evan)
> > HighGo Software Co., Ltd.
> > https://www.highgo.com/
> >
> >
> >
> >
>
> Oops, forgot the attachment. Here comes it.
>
> Best regards,
> --
> Chao Li (Evan)
> HighGo Software Co., Ltd.
> https://www.highgo.com/
>
>
>
>
> Thanks for the patch. I just reproduced the problem and verified the fix.
So this patch looks good to me.

Regards,
Lu Feng

  4. Re: Avoid leaking system path from pg_available_extensions

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-05-21T15:12:56Z

    On 19/05/26 22:00, Chao Li wrote:
> I just tested “Add paths of extensions to pg_available_extensions”, and found an issue.
> 
> This is a simple repro:
> ```
> evantest=# reset extension_control_path;
> RESET
> evantest=# select * from pg_available_extensions where name = 'plpgsql';
>    name   | default_version | installed_version | location |           comment
> ---------+-----------------+-------------------+----------+------------------------------
>   plpgsql | 1.0             | 1.0               | $system  | PL/pgSQL procedural language
> (1 row)
> 
> evantest=# set extension_control_path='';
> SET
> evantest=# select * from pg_available_extensions where name = 'plpgsql';
>    name   | default_version | installed_version |             location             |           comment
> ---------+-----------------+-------------------+----------------------------------+------------------------------
>   plpgsql | 1.0             | 1.0               | /usr/local/pgsql/share/extension | PL/pgSQL procedural language
> (1 row)
> ```
> 
> When extension_control_path is not set, location shows “$system", which is consistent with what the documentation says:
> ```
>         <para>
>          The default value for this parameter is
>          <literal>'$system'</literal>. If the value is set to an empty
>          string, the default <literal>'$system'</literal> is also assumed.
>         </para>
> ```
> 
> However, as shown above, when I set extension_control_path to an empty string, the absolute system path is displayed. I consider this an information leakage bug.
> 
> The fix is straightforward; see the attached patch for details. After the fix, when extension_control_path is an empty string, location shows “$system” now:
> ```
> evantest=# set extension_control_path='';
> SET
> evantest=# select * from pg_available_extensions where name = 'plpgsql';
>    name   | default_version | installed_version | location |           comment
> ---------+-----------------+-------------------+----------+------------------------------
>   plpgsql | 1.0             | 1.0               | $system  | PL/pgSQL procedural language
> (1 row)
> ```
> 

Hi, thank you for sharing the bug with the fix.

I've reproduced the issue and the fix looks correct to me.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

  5. Re: Avoid leaking system path from pg_available_extensions

    Jim Jones <jim.jones@uni-muenster.de> — 2026-05-22T07:25:54Z

    On 21/05/2026 17:12, Matheus Alcantara wrote:
> I've reproduced the issue and the fix looks correct to me.

same here, +1

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.

Thanks!

Best, Jim

  6. Re: Avoid leaking system path from pg_available_extensions

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-05-22T15:40:28Z

    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.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

  7. Re: Avoid leaking system path from pg_available_extensions

    Chao Li <li.evan.chao@gmail.com> — 2026-05-26T07:14:25Z

    
> On May 22, 2026, at 23:40, Matheus Alcantara <matheusssilv97@gmail.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.
> 
> --
> Matheus Alcantara
> EDB: https://www.enterprisedb.com

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.
Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/

  8. Re: Avoid leaking system path from pg_available_extensions

    Jim Jones <jim.jones@uni-muenster.de> — 2026-05-26T10:02:45Z

    On 26/05/2026 09:14, Chao Li wrote:
> 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.


I don't feel strongly about it. I only brought it up because hardcoded
strings used in multiple places are usually a recipe for oversights and
painful debugging down the road. That said, as I mentioned, I understand
the argument that this is scoped to a single function, and the fact
they're pretty close to one another also makes it less likely to be
missed, but there is no guarantee it'll stay like that forever.

Thanks for the fix!

Best, Jim

  9. Re: Avoid leaking system path from pg_available_extensions

    Matheus Alcantara <matheusssilv97@gmail.com> — 2026-05-26T13:29:58Z

    On 26/05/26 04:14, Chao Li wrote:
> 
> 
>> On May 22, 2026, at 23:40, Matheus Alcantara <matheusssilv97@gmail.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.

--
Matheus Alcantara
EDB: https://www.enterprisedb.com

  10. Re: Avoid leaking system path from pg_available_extensions

    Andrew Dunstan <andrew@dunslane.net> — 2026-05-30T13:21:21Z

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

  11. Re: Avoid leaking system path from pg_available_extensions

    Chao Li <li.evan.chao@gmail.com> — 2026-05-31T04:26:51Z

    
> On May 30, 2026, at 21:21, Andrew Dunstan <andrew@dunslane.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@gmail.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/