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

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: Row Level Security − leakproof-ness and performance implications
Дата
Msg-id 98db30f1-f9f9-2f2c-c00a-2c19e126274a@joeconway.com
обсуждение исходный текст
Ответ на Re: Row Level Security − leakproof-ness andperformance implications  (Laurenz Albe <laurenz.albe@cybertec.at>)
Список 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


Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Remove unnecessary use of PROCEDURAL
Следующее
От: Nikita Glukhov
Дата:
Сообщение: Re: [PATCH] kNN for btree