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