Re: row_security GUC, BYPASSRLS

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: row_security GUC, BYPASSRLS
Дата
Msg-id CA+TgmoYTfsECYYLZ=FWxUmSVRLxGj41aToxV3hK-4HA+wBU2Vw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: row_security GUC, BYPASSRLS  (Noah Misch <noah@leadboat.com>)
Список pgsql-hackers
On Thu, Oct 1, 2015 at 11:10 PM, Noah Misch <noah@leadboat.com> wrote:
> On Mon, Sep 28, 2015 at 05:13:56PM -0400, Stephen Frost wrote:
>> * Noah Misch (noah@leadboat.com) wrote:
>> > In schema reviews, I will raise a red flag for use of this feature; the best
>> > designs will instead use additional roles.  I forecast that PostgreSQL would
>> > fare better with no owner-constrained-by-RLS capability.  Even so, others want
>> > it, and FORCE ROW SECURITY would deliver it with an acceptable risk profile.
>>
>> I've attached a patch to implement it.  It's not fully polished but it's
>> sufficient for comment, I believe.  Additional comments, documentation
>> and regression tests are to be added, if we have agreement on the
>> grammer and implementation approach.
>
> This patch has FORCE ROW LEVEL SECURITY take precedence over row_security=off,
> which thwarts pg_dump use of row_security=off to ensure dump completeness.

Yeah, I think that's NOT ok.

> Should this be a table-level flag, or should it be a policy-level flag?  A
> policy-level flag is more powerful.  If nobody really anticipates using that
> power, this table-level flag works for me.

Either works for me.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Potential GIN vacuum bug
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Request for dogfood volunteers (was No Issue Tracker - Say it Ain't So!)