On Wed, Jul 2, 2014 at 9:47 AM, Stephen Frost <sfr...@snowman.net> wrote:
>> But you could do it other ways.  For example:
>> 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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to