Re: row_security GUC, BYPASSRLS

From: Noah Misch <noah(at)leadboat(dot)com>
To: Adam Brightwell <adam(dot)brightwell(at)crunchydatasolutions(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Stephen Frost <sfrost(at)snowman(dot)net>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: row_security GUC, BYPASSRLS
Date: 2015-09-18 06:07:19
Message-ID: 20150918060719.GB3682120@tornado.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Sep 15, 2015 at 03:18:21PM -0400, Adam Brightwell wrote:
> On Tue, Sep 15, 2015 at 2:26 PM, Joe Conway <mail(at)joeconway(dot)com> wrote:
> >> Joe Conway <mail(at)joeconway(dot)com> writes:
> >>> There are use cases where row_security=force will be set in production
> >>> environments, not only in testing.

> > Noah's suggestion of using a per table attribute
> > would work -- in fact I like the idea of that better than using the
> > current GUC.
>
> FWIW, I also concur with a per table attribute for this purpose. In
> fact, I think I really like the per-table flexibility over an
> 'all-or-nothing' approach better too.

Great. Robert, does that work for you, too? If so, this sub-thread is
looking at three patches:

1. remove row_security=force
2. remove SECURITY_ROW_LEVEL_DISABLED; make ri_triggers.c subject to policies
3. add DDL-controlled, per-table policy forcing

They ought to land in that order. PostgreSQL 9.5 would need at least (1) and
(2); would RLS experts find it beneficial for me to take care of those?

Thanks,
nm

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Janes 2015-09-18 06:13:07 Re: creating extension including dependencies
Previous Message lacesco 2015-09-18 06:04:24 Fw: important message