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