MIME-Version: 1.0
References: 
 <CALHMmB84qkCgv3QAR78YawgfqQZCxSPkRhppxzU=e6fg8RA+AA@mail.gmail.com>
 <CALdSSPiAmy3ZoUyRXMqFazm0D0b1Y4oMhUKVpXwSBhrDh+odew@mail.gmail.com>
In-Reply-To: 
 <CALdSSPiAmy3ZoUyRXMqFazm0D0b1Y4oMhUKVpXwSBhrDh+odew@mail.gmail.com>
From: Vismay Tiwari <vismay.t@gmail.com>
Date: Fri, 10 Jul 2026 11:21:36 +0530
Message-ID: 
 <CALHMmB9hbLK5cxC0Nto+YFXBhFY3pC0=LxZ=QhF_SUVWOfqnog@mail.gmail.com>
Subject: Re: BUG #19523: psql tab-completion shadows pg_db_role_setting
To: Kirill Reshke <reshkekirill@gmail.com>
Cc: PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CALHMmB9hbLK5cxC0Nto%2BYFXBhFY3pC0%3DLxZ%3DQhF_SUVWOfqnog%40mail.gmail.com>
Precedence: bulk

Hi Kirill,

Thanks, and sorry for the two threads =E2=80=94 the second was an accidenta=
l
resend that didn't thread properly on my end , so let's keep it here.

You're right that it's not a vulnerability, and the "attacker" framing
was overblown =E2=80=94 the docs are clear that removing publicly-writable
schemas from search_path is the real safeguard. The intent is just
consistency and robustness: the same query already qualifies
unnest()/split_part() with pg_catalog, and the analogous
subscription-variable completion query qualifies its catalogs, so this
only brings pg_db_role_setting/pg_database in line. As a side benefit
it avoids a surprising tab-completion result for anyone who happens to
have a same-named table earlier in search_path, misconfigured or not.

Thanks for the +1.

Regards,
Vismay

On Fri, Jul 10, 2026 at 10:19=E2=80=AFAM Kirill Reshke <reshkekirill@gmail.=
com> wrote:
>
>
> Hi! You seem to create two threads on the issue, so I don't quite underst=
and where to respond. anyway:
>
> On Thu, 9 Jul 2026, 15:14 Vismay Tiwari, <vismay.t@gmail.com> wrote:
>>
>> Hi,
>>
>> Reproduced on current master. The tab-completion query for
>> "ALTER DATABASE ... RESET" (Query_for_list_of_database_vars) references
>> pg_db_role_setting and pg_database without a pg_catalog qualification, s=
o a
>> same-named table earlier in search_path shadows the catalog:
>>
>>     CREATE SCHEMA attacker;
>>     CREATE TABLE attacker.pg_db_role_setting (setdatabase oid, setrole
>> oid, setconfig text[]);
>>     INSERT INTO attacker.pg_db_role_setting
>>       SELECT oid, 0, ARRAY['evil_var=3Dx'] FROM pg_database WHERE
>> datname =3D 'postgres';
>>     SET search_path =3D attacker, pg_catalog;
>>     -- "ALTER DATABASE postgres RESET <TAB>" then offers evil_var
>>
>
> Preventing this makes sense in case somebody accidentally misconfigured t=
heir server. Which is not very probable for a table with `pg_db_role_settin=
g` name.
> Also note that this is not a vulnerability: from https://www.postgresql.o=
rg/docs/current/app-psql.html says:
>
>   If untrusted users have access to a database that has not adopted a sec=
ure
>   schema usage pattern, begin your session by removing publicly-writable
>   schemas from search_path.
>
> Anyway +1 on fixing
>
>