Re: Redact user password on pg_stat_statements

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