On Wed, Jul 2, 2014 at 9:47 AM, Stephen Frost <sfrost@snowman.net> wrote:
>> But you could do it other ways. For example:
>>
>> ALTER TABLE table_name [ NO ] ROW LEVEL SECURITY;
>> ALTER TABLE table_name GRANT ROW ACCESS TO role_name USING qual;
>>
>> If a table is set to NO ROW LEVEL SECURITY then it behaves just like
>> it does now: anyone who accesses it sees all the rows, restricted to
>> those columns for which they have permission. If the table is set to
>> ROW LEVEL SECURITY then the default is to show no rows. The second
>> command then allows access to a subset of the rows for a give role
>> name. In this case, it is probably logical for access to be combined
>> via OR.
>
> I can see value is having a table-level option to indicate if RLS is
> applied for that table or not, but I had been thinking we'd just
> automatically manage that. That is to say that once you define an RLS
> policy for a table, we go look and see what policy should be applied in
> each case. With the user able to control that, what happens if they say
> "row security" on the table and there are no policies? All access would
> show the table as empty?
I said the same thing in the text you quoted immediately above this reply.
> What if policies exist and they decide to
> 'turn off' RLS for the table- suddenly everyone can see all the rows?
That'd be my vote. Sorta like disabling triggers.
> Are we getting to a point where there is sufficient agreement that it'd
> be worthwhile to really start implementing this?
I think we're converging, but it might be a good idea to summarize a
specific proposal before you start implementing.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company