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

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: Row Level Security − leakproof-ness and performance implications
Дата
Msg-id 02b89715-9376-62ce-55ff-ef0df92f9712@joeconway.com
обсуждение исходный текст
Ответ на Re: Row Level Security − leakproof-ness and performance implications  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Row Level Security − leakproof-ness and performance implications  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On 2/28/19 11:50 AM, Robert Haas wrote:
> On Thu, Feb 28, 2019 at 11:44 AM Joe Conway <mail@joeconway.com> wrote:
>> No, and Tom stated as much too, but life is all about tradeoffs. Some
>> people will find this an acceptable compromise. For those that don't
>> they don't have to use it. IMHO we tend toward too much nannyism too often.
>
> Well, I agree with that, too.
>
> Hmm.  I don't think there's anything preventing you from implementing
> this in "userspace," is there?  A logging hook could suppress all
> error message text, and you could just mark all functions leakproof
> after that, and you'd have this exact behavior in an existing release
> with no core code changes, I think.

I think that would affect the server logs too, no? Worth thinking about
though...

Also manually marking all functions leakproof is far less convenient
than turning off the check as this patch effectively allows. You would
want to keep track of the initial condition and be able to restore it if
needed. Doable but much uglier. Perhaps we could tolerate a hook that
would allow an extension to do this though?

> If you do that, or just stick this patch into your own distro, I would
> be interested to hear some experiences from customers (and those who
> support them) after some time had gone by.  I find it hard to imagine
> delivering customer support in an environment configured this way, but
> sometimes my imagination is limited.

Again, remember that the actual messages are available in the server
logs. The presumption is that the server logs are kept secure, and it is
ok to leak information into them. How the customer does or does not
decide to pass some of that information on to a support group becomes a
problem to deal with on a case by case basis.

Also, as mentioned up-thread, in many cases there is or should be a
non-production instance available to use for reproducing problems to
debug them. Presumably the data on such a system is faked or has already
been cleaned up for a wider audience.

Joe

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


Вложения

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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Row Level Security − leakproof-ness and performance implications
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Row Level Security − leakproof-ness and performance implications