Re: row_security GUC, BYPASSRLS

On Tue, Sep 15, 2015 at 2:26 PM, Joe Conway <mail(at)joeconway(dot)com> wrote:
> On 09/15/2015 12:53 PM, Tom Lane 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.
>>
>> What cases, exactly, and is there another way to solve those problems?
>> I concur with Noah's feeling that allowing security behavior to depend on
>> a GUC is risky.
>
> There are environments where there is a strong desire to use RLS to
> control access in production, even for table owners and superusers.
> Obviously there are more steps needed to completely achieve this level
> of control, but removing the ability to force row security is going in
> the wrong direction. 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.

I do, however, think that it makes it a bit more difficult for
testing, specifically, I'm not sure how much I like the idea of
'altering' a table so that it can be tested, but that might a price
worth paying for security sake.

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-case, at least at a system level). Since you
can't GRANT 'alter' rights to the table, then obviously the policy
definer would have to either be the owner of the table or a member of
the role that owns it, right? Given that, if by definition the policy
definer is not allowed to do anything other than define policies, then
obviously putting such a role in the table owners group would allow it
to do much more, correct?

-Adam

--
Adam Brightwell - adam(dot)brightwell(at)crunchydatasolutions(dot)com
Database Engineer - www.crunchydatasolutions.com