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
