* Noah Misch (n...@leadboat.com) wrote:
> On Mon, Sep 28, 2015 at 05:13:56PM -0400, Stephen Frost wrote:
> > * Noah Misch (n...@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
On Thu, Oct 1, 2015 at 11:10 PM, Noah Misch wrote:
> On Mon, Sep 28, 2015 at 05:13:56PM -0400, Stephen Frost wrote:
>> * Noah Misch (n...@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
On Mon, Sep 28, 2015 at 05:13:56PM -0400, Stephen Frost wrote:
> * Noah Misch (n...@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-co
> 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.
I have given the first patch a quick review
* Noah Misch (n...@leadboat.com) wrote:
> On Tue, Sep 22, 2015 at 10:38:53AM -0400, Stephen Frost wrote:
> > This would lead to trivial to cause (and likely hard to diagnose)
> > referential integrity data corruption issues. I find that a very hard
> > pill to swallow in favor of a theoretical con
* Noah Misch (n...@leadboat.com) wrote:
> On Thu, Sep 10, 2015 at 03:23:13PM -0400, Stephen Frost wrote:
> > First off, thanks again for your review and comments on RLS. Hopefully
> > this addresses the last remaining open item from that review.
>
> Item (3a), too, remains open.
Provided I didn'
On Tue, Sep 22, 2015 at 10:38:53AM -0400, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > On Mon, Sep 21, 2015 at 09:30:15AM -0400, Stephen Frost wrote:
> > > One item which wasn't discussed, that I recall, is just how it will work
> > > without SECURITY_ROW_LEVEL_DISABLED, or so
* Noah Misch (n...@leadboat.com) wrote:
> On Mon, Sep 21, 2015 at 09:30:15AM -0400, Stephen Frost wrote:
> > * Noah Misch (n...@leadboat.com) wrote:
> > > Right now, if a BYPASSRLS user creates a SECURITY DEFINER function, any
> > > caller
> > > can change that function's behavior by toggling the
On Mon, Sep 21, 2015 at 09:30:15AM -0400, Stephen Frost wrote:
> * Noah Misch (n...@leadboat.com) wrote:
> > Right now, if a BYPASSRLS user creates a SECURITY DEFINER function, any
> > caller
> > can change that function's behavior by toggling the GUC. Users won't test
> > accordingly; better to
* Noah Misch (n...@leadboat.com) wrote:
> Right now, if a BYPASSRLS user creates a SECURITY DEFINER function, any caller
> can change that function's behavior by toggling the GUC. Users won't test
> accordingly; better to have just one success-case behavior.
I agree that's not good, though the fu
On Mon, Sep 14, 2015 at 03:29:16AM -0400, Noah Misch wrote:
> On a related topic, check_enable_rls() has two kinds of RLS bypass semantics.
> Under row_security=off|on, superusers bypass every policy, and table owners
> bypass policies of their own tables. Under row_security=off only, roles with
>
On Fri, Sep 18, 2015 at 09:27:13AM -0500, Joe Conway wrote:
> On 09/18/2015 09:25 AM, Adam Brightwell wrote:
> >>> 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
> >>>
> >>
Robert Haas writes:
> On Sun, Sep 20, 2015 at 5:35 PM, Stephen Frost wrote:
>> * Joe Conway (m...@joeconway.com) wrote:
>>> That would be awesome, but I would say that if we do #1 & 2 for 9.5, we
>>> also need #3.
>> Agreed on all of the above.
> Well, then, we should get cracking. beta1 is co
On Sun, Sep 20, 2015 at 5:35 PM, Stephen Frost wrote:
> * Joe Conway (m...@joeconway.com) wrote:
>> On 09/18/2015 01:07 AM, Noah Misch wrote:
>> > Great. Robert, does that work for you, too? If so, this sub-thread is
>> > looking at three patches:
>> >
>> > 1. remove row_security=force
>> > 2. r
* Joe Conway (m...@joeconway.com) wrote:
> On 09/18/2015 01:07 AM, Noah Misch wrote:
> > 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
On Fri, Sep 18, 2015 at 09:01:15AM -0400, Adam Brightwell wrote:
> > 2. remove SECURITY_ROW_LEVEL_DISABLED; make ri_triggers.c subject to
> > policies
>
> I believe this one has already been addressed by Stephen
> (20150910192313.gt3...@tamriel.snowman.net)? Are there further
> considerations fo
On 09/18/2015 09:25 AM, Adam Brightwell wrote:
>>> 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
>> 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
On 09/18/2015 01:07 AM, Noah Misch wrote:
> 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
On Fri, Sep 18, 2015 at 2:07 AM, Noah Misch wrote:
> On Tue, Sep 15, 2015 at 03:18:21PM -0400, Adam Brightwell wrote:
>> On Tue, Sep 15, 2015 at 2:26 PM, Joe Conway wrote:
>> >> Joe Conway writes:
>> >>> There are use cases where row_security=force will be set in production
>> >>> environments,
> 2. remove SECURITY_ROW_LEVEL_DISABLED; make ri_triggers.c subject to policies
I believe this one has already been addressed by Stephen
(20150910192313.gt3...@tamriel.snowman.net)? Are there further
considerations for his proposed changes?
-Adam
--
Adam Brightwell - adam.brightw...@crunchydat
On Tue, Sep 15, 2015 at 03:18:21PM -0400, Adam Brightwell wrote:
> On Tue, Sep 15, 2015 at 2:26 PM, Joe Conway wrote:
> >> Joe Conway 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
> I could also see a potential gap in such approach. Specifically, I
> could see a case were there are two separate roles, one that is
> entrusted with defining the policies but not able to create/modify
> tables, and one with the opposite capability (I understand this to be
> a fairly common use-
On Tue, Sep 15, 2015 at 2:26 PM, Joe Conway wrote:
> On 09/15/2015 12:53 PM, Tom Lane wrote:
>> Joe Conway writes:
>>> There are use cases where row_security=force will be set in production
>>> environments, not only in testing.
>>
>> What cases, exactly, and is there another way to solve those p
On 09/15/2015 12:53 PM, Tom Lane wrote:
> Joe Conway writes:
>> There are use cases where row_security=force will be set in production
>> environments, not only in testing.
>
> What cases, exactly, and is there another way to solve those problems?
> I concur with Noah's feeling that allowing secu
Joe Conway writes:
> On 09/15/2015 10:58 AM, Robert Haas wrote:
>> 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.
> There are use cases where row_security=force will be set in produ
On 09/15/2015 11:10 AM, Tom Lane wrote:
> Robert Haas writes:
>> On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch 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
On 09/15/2015 10:58 AM, Robert Haas wrote:
> 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.
There are use cases where row_security=force will be set in production
environments, not onl
Robert Haas writes:
> On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch 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.
On Tue, Sep 15, 2015 at 1:00 AM, Noah Misch wrote:
>> ...but I'm not sure I like this, either. Without row_security=force,
>> it's hard for a table owner to test their policy, unless they have the
>> ability to assume some other user ID, which some won't. If someone
>> puts in place a policy whi
Noah Misch writes:
> On Mon, Sep 14, 2015 at 07:30:33AM -0400, Robert Haas wrote:
>> ...but I'm not sure I like this, either. Without row_security=force,
>> it's hard for a table owner to test their policy, unless they have the
>> ability to assume some other user ID, which some won't. If someon
On Mon, Sep 14, 2015 at 07:30:33AM -0400, Robert Haas wrote:
> On Mon, Sep 14, 2015 at 3:29 AM, Noah Misch wrote:
> > Pondering it afresh this week, I see now that row_security=force itself is
> > the
> > problem. It's a new instance of the maligned "behavior-changing GUC".
> > Function authors
On Mon, Sep 14, 2015 at 3:29 AM, Noah Misch wrote:
> SECURITY DEFINER execution blocks SET ROLE, SET SESSION AUTHORIZATION, and
> sometimes "GRANT role1 TO role2". Otherwise, it works like regular execution.
> Adding exceptions, particularly silent behavior changes as opposed to hard
> errors, is
On Thu, Sep 10, 2015 at 03:23:13PM -0400, Stephen Frost wrote:
> First off, thanks again for your review and comments on RLS. Hopefully
> this addresses the last remaining open item from that review.
Item (3a), too, remains open.
> * Noah Misch (n...@leadboat.com) wrote:
> > On Wed, Feb 25, 2015
34 matches
Mail list logo
