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 eff95189-72fb-471c-83dc-d61a79afb637@dunslane.net
Whole thread Raw
In response to Re: Redact user password on pg_stat_statements  (Peter Eisentraut <peter@eisentraut.org>)
Responses Re: Redact user password on pg_stat_statements
List pgsql-hackers
On 2025-02-24 Mo 11:04 AM, Peter Eisentraut wrote:
> On 21.02.25 17:38, Andrew Dunstan wrote:
>> 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.
>
> To me, the mechanism by which this patch works is completely 
> nonobvious and coincidental, and it might get broken by unrelated 
> changes.
>
> I think a possible, more robust approach would be to put a field, say, 
> security_sensitive into DefElem (or maybe a higher node, maybe even 
> Query), and drive decisions from that.


That's a fair comment, but I don't see any point in Matheus or anyone 
else working on it if we're going to reject it anyway. Probably nothing 
we could do is going to be completely leakproof (see Sami's case 
upthread abut DO blocks). If that means we avoid all attempts do lessen 
the danger here then I guess we are done.


cheers


andrew

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




pgsql-hackers by date:

Previous
From: "Daniel Verite"
Date:
Subject: Re: pgbench client-side performance issue on large scripts
Next
From: Fujii Masao
Date:
Subject: Re: Extend postgres_fdw_get_connections to return remote backend pid