public inbox for [email protected]  

help / color / mirror / Atom feed

From: Vismay Tiwari <[email protected]>
To: Kirill Reshke <[email protected]>
Cc: PostgreSQL mailing lists <[email protected]>
Subject: Re: BUG #19523: psql tab-completion shadows pg_db_role_setting
Date: Fri, 10 Jul 2026 11:21:36 +0530
Message-ID: <CALHMmB9hbLK5cxC0Nto+YFXBhFY3pC0=LxZ=QhF_SUVWOfqnog@mail.gmail.com> (raw)
In-Reply-To: <CALdSSPiAmy3ZoUyRXMqFazm0D0b1Y4oMhUKVpXwSBhrDh+odew@mail.gmail.com>
References: <CALHMmB84qkCgv3QAR78YawgfqQZCxSPkRhppxzU=e6fg8RA+AA@mail.gmail.com>
	<CALdSSPiAmy3ZoUyRXMqFazm0D0b1Y4oMhUKVpXwSBhrDh+odew@mail.gmail.com>

Hi Kirill,

Thanks, and sorry for the two threads — the second was an accidental
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 — 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 AM Kirill Reshke <[email protected]> wrote:
>
>
> Hi! You seem to create two threads on the issue, so I don't quite understand where to respond. anyway:
>
> On Thu, 9 Jul 2026, 15:14 Vismay Tiwari, <[email protected]> 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, so 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=x'] FROM pg_database WHERE
>> datname = 'postgres';
>>     SET search_path = attacker, pg_catalog;
>>     -- "ALTER DATABASE postgres RESET <TAB>" then offers evil_var
>>
>
> Preventing this makes sense in case somebody accidentally misconfigured their server. Which is not very probable for a table with `pg_db_role_setting` name.
> Also note that this is not a vulnerability: from https://www.postgresql.org/docs/current/app-psql.html says:
>
>   If untrusted users have access to a database that has not adopted a secure
>   schema usage pattern, begin your session by removing publicly-writable
>   schemas from search_path.
>
> Anyway +1 on fixing
>
>

view thread (4+ messages)

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: [email protected]
  Cc: [email protected], [email protected], [email protected]
  Subject: Re: BUG #19523: psql tab-completion shadows pg_db_role_setting
  In-Reply-To: <CALHMmB9hbLK5cxC0Nto+YFXBhFY3pC0=LxZ=QhF_SUVWOfqnog@mail.gmail.com>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox