On Tue, Sep 15, 2015 at 2:26 PM, Joe Conway <m...@joeconway.com> wrote: > On 09/15/2015 12:53 PM, Tom Lane wrote: >> Joe Conway <m...@joeconway.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.brightw...@crunchydatasolutions.com Database Engineer - www.crunchydatasolutions.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
