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



Reply via email to