Re: Row Level Security − leakproof-ness and performance implications

From: Joe Conway <mail(at)joeconway(dot)com>
To: Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at>, Pierre Ducroquet <p(dot)psql(at)pinaraf(dot)info>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Row Level Security − leakproof-ness and performance implications
Date: 2019-02-20 14:46:35
Message-ID: 98db30f1-f9f9-2f2c-c00a-2c19e126274a@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Nikita Glukhov 2019-02-20 14:46:47 Re: [PATCH] kNN for btree
Previous Message Peter Eisentraut 2019-02-20 14:39:21 Remove unnecessary use of PROCEDURAL