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