Re: row_security GUC, BYPASSRLS

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: row_security GUC, BYPASSRLS
Дата
Msg-id 55F84736.5080909@joeconway.com
обсуждение исходный текст
Ответ на Re: row_security GUC, BYPASSRLS  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On 09/15/2015 11:10 AM, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch <noah@leadboat.com> wrote:
>>> It also requires a DBA unwilling to
>>> furnish test accounts to custodians of sensitive data.  With or without
>>> row_security=force, such a team is on the outer perimeter of the audience able
>>> to benefit from RLS.  Nonetheless, I'd welcome a replacement test aid.
>
>> I can't argue with that, I suppose, but I think row_security=force is
>> a pretty useful convenience.  If we must remove it, so be it, but I'd
>> be a little sad.
>
> Keep in mind that if you have an uncooperative DBA on your production
> system, you can always test your policy to your heart's content on a
> playpen installation.  In fact, most people would consider that good
> engineering practice anyway, rather than pushing untested code directly
> into production.


That's exactly right. We should provide flexibility for testing in test
environments, and also the ability to lock things down tight in production.

Joe

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


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

Предыдущее
От: Joe Conway
Дата:
Сообщение: Re: row_security GUC, BYPASSRLS
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: cache type info in json_agg and friends