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

From Andrew Dunstan
Subject Re: Redact user password on pg_stat_statements
Date
Msg-id 62bdb651-077b-48d5-96f9-67581bee0acd@dunslane.net
Whole thread Raw
In response to Re: Redact user password on pg_stat_statements  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Redact user password on pg_stat_statements
List pgsql-hackers
On 2025-02-21 Fr 11:08 AM, Tom Lane wrote:
> Matheus Alcantara <matheusssilv97@gmail.com> writes:
>> Attached a patch to redact the password value from pg_stat_statements_view when
>> executing:
>> { CREATE|ALTER} {USER|ROLE|GROUP } identifier { [WITH] [ENCRYPTED]
>> PASSWORD 'value' }
> 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.
> One obvious objection to the direction you propose here is that it
> does nothing for pg_stat_activity, nor for the server log if
> log_statement is enabled.
>
> The right answer is to never send cleartext passwords to the server
> in the first place.
>
>             regards, tom lane
>
> [1] https://www.postgresql.org/message-id/flat/18817-771682052a364bfe%40postgresql.org
>
>


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.

I agree that people should not send passwords in cleartext, but I don't 
know that that means we should never try to ameliorate the risk of doing so.


cheers


andrew

--
Andrew Dunstan
EDB: https://www.enterprisedb.com




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Redact user password on pg_stat_statements
Next
From: Andres Freund
Date:
Subject: Re: TAP test started using meson, can get a tcp port already used by another test.