Re: Row Level Security − leakproof-ness and performance implications - Mailing list pgsql-hackers

From Joe Conway
Subject Re: Row Level Security − leakproof-ness and performance implications
Date
Msg-id 98db30f1-f9f9-2f2c-c00a-2c19e126274a@joeconway.com
Whole thread Raw
In response to Re: Row Level Security − leakproof-ness andperformance implications  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-hackers
On 2/19/19 6:43 PM, Laurenz Albe wrote:
> Pierre Ducroquet wrote:
>> if we had a 'RLS-enabled' context on functions, a way to make a lot of built-
>> in functions leakproof would simply be to prevent them from logging errors
>> containing values.
>>
>> For others, like arraycontains, it's much trickier :[...]
>
> I feel a little out of my depth here, so I won't comment.

I had more-or-less the same idea, and even did a PoC patch (not
preventing the log entries but rather redacting the variable data), but
after discussing offlist with some other hackers I got the impression
that it would be a really hard sell.

It does seem to me though that such a feature would be pretty useful.
Something like use a GUC to turn it on, and while on log messages get
redacted. If you really needed to see the details, you could either
duplicate your issue on another installation with the redaction turned
off, or maybe turn it off on production in a controlled manner just long
enough to capture the full error message.

Joe

--
Crunchy Data - http://crunchydata.com
PostgreSQL Support for Secure Enterprises
Consulting, Training, & Open Source Development


Attachment

pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Remove unnecessary use of PROCEDURAL
Next
From: Nikita Glukhov
Date:
Subject: Re: [PATCH] kNN for btree