Re: Redact user password on pg_stat_statements

Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
> On 2025-02-21 Fr 11:08 AM, Tom Lane wrote:
>> Please see previous threads about hiding this sort of information,
>> most recently [1]. It's a slippery slope for which there are no
>> real fixes, and even partial fixes like this one are horrid kluges.

> I don't think this is such a terrible kluge. I think it's different from
> the server log case, which after all requires access to the server file
> system to exploit.

Well, pg_stat_statements requires pg_read_all_stats membership before
it will show you query text, so there is a permissions gate to pass
here too. (I think the description of that role in user-manag.sgml
is perhaps not sufficiently explicit about how much power it has;
it's not apparent that it lets you see other sessions' queries.)

But the real reason that I'm allergic to this idea is that it sets
a precedent that we will attempt to hide such information. Once
we do that, it becomes a lot harder to argue that leakage paths
like the postmaster log or pg_stat_activity aren't security bugs.

regards, tom lane