Re: Redact user password on pg_stat_statements - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Redact user password on pg_stat_statements
Date
Msg-id 3139897.1740157064@sss.pgh.pa.us
Whole thread Raw
In response to Re: Redact user password on pg_stat_statements  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Andrew Dunstan <andrew@dunslane.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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: TAP test started using meson, can get a tcp port already used by another test.
Next
From: Mark Dilger
Date:
Subject: Re: Amcheck verification of GiST and GIN