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. Joe -- Crunchy Data - http://crunchydata.com PostgreSQL Support for Secure Enterprises Consulting, Training, & Open Source Development
signature.asc
Description: OpenPGP digital signature
