On Sat, Sep 6, 2014 at 2:54 AM, Brightwell, Adam
<adam.brightw...@crunchydatasolutions.com> wrote:
> * Add ALTER TABLE <name> { ENABLE | DISABLE } ROW LEVEL SECURITY - set flag
> on table to allow for a default-deny capability. If RLS is enabled on a
> table and has no policies, then a default-deny policy is automatically
> applied. If RLS is disabled on table and the table still has policies on it
> then then an error is raised. Though if DISABLE is accompanied with
> CASCADE, then all policies will be removed and no error is raised.
This text doesn't make it clear that all of the cases have been
covered; in particular, you didn't specify whether an error is thrown
if you try to add a policy to a table with DISABLE ROW LEVEL SECURITY
in effect. Backing up a bit, I think there are two sensible designs
here:
1. Row level security policies can't exist for a table with DISABLE
ROW LEVEL SECURITY in effect. It sounds like this is what you have
implemented, modulo any hypothetical bugs. You can't add policies
without enabling RLS, and you can't disable RLS without dropping them
all.
2. Row level security policies can exist for a table with DISABLE ROW
LEVEL SECURITY in effect, but they don't do anything until RLS is
enabled. A possible advantage of this approach is that you could
*temporarily* shut off RLS for a table without having to drop all of
your policies and put them back. I kind of like this approach; we
have something similar for triggers, and I think it could be useful to
people.
If you stick with approach #1, make sure pg_dump is guaranteed to
enable RLS before applying the policies. And either way, you should
that pg_dump behaves sanely in the case where there are circular
dependencies, like you have two table A and B, and each has a RLS
policy that manages to use the other table's row-type. (You probably
also want to check that DROP and DROP .. CASCADE on either policy or
either table does the right thing in that situation, but that's
probably easier to get right.)
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
