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 по дате отправления: