FORCE ROW LEVEL SECURITY

Robert,

* Robert Haas (robertmhaas@gmail.com) wrote:

FORCE ROW LEVEL SECURITY doesn't behave as I would expect.

rhaas=# create policy hideit on foo1 using (a < 3);
CREATE POLICY
rhaas=# explain select * from foo1;
QUERY PLAN
---------------------------------------------------------
Seq Scan on foo1 (cost=0.00..22.70 rows=1270 width=36)
(1 row)
rhaas=# alter table foo force row level security;
ALTER TABLE
rhaas=# alter table foo1 enable row level security;
ALTER TABLE
rhaas=# explain select * from foo1;
QUERY PLAN
---------------------------------------------------------
Seq Scan on foo1 (cost=0.00..22.70 rows=1270 width=36)
(1 row)
rhaas=# create user bob;
CREATE ROLE
rhaas=# grant select on foo1 to bob;
GRANT
rhaas=# \c - bob
You are now connected to database "rhaas" as user "bob".
rhaas=> select * from foo1;
a | b
---+---
(0 rows)

rhaas=> explain select * from foo1;
QUERY PLAN
--------------------------------------------------------
Seq Scan on foo1 (cost=0.00..25.88 rows=423 width=36)
Filter: (a < 3)
(2 rows)

Isn't the whole purpose of FORCE ROW LEVEL SECURITY to cause RLS to be
applied even for the table owner?

Did you enable RLS for the table?

You need to do both ENABLE and FORCE if you want it to apply to owners.
There are regressions tests which should demonstrate that, if it helps.
Happy to work through the issue also though.

Thanks!

Stephen

* Robert Haas (robertmhaas@gmail.com) wrote:

FORCE ROW LEVEL SECURITY doesn't behave as I would expect.

rhaas=# create policy hideit on foo1 using (a < 3);
CREATE POLICY
rhaas=# explain select * from foo1;
QUERY PLAN
---------------------------------------------------------
Seq Scan on foo1 (cost=0.00..22.70 rows=1270 width=36)
(1 row)
rhaas=# alter table foo force row level security;
ALTER TABLE
rhaas=# alter table foo1 enable row level security;
ALTER TABLE

Sorry if my prior wasn't clear, but above you do 'foo' and 'foo1'
independently.

Did you intend to alter table 'foo'?

Thanks!

Stephen

On Wed, Nov 4, 2015 at 1:48 PM, Stephen Frost <sfrost@snowman.net> wrote:

* Robert Haas (robertmhaas@gmail.com) wrote:

FORCE ROW LEVEL SECURITY doesn't behave as I would expect.

rhaas=# create policy hideit on foo1 using (a < 3);
CREATE POLICY
rhaas=# explain select * from foo1;
QUERY PLAN
---------------------------------------------------------
Seq Scan on foo1 (cost=0.00..22.70 rows=1270 width=36)
(1 row)
rhaas=# alter table foo force row level security;
ALTER TABLE
rhaas=# alter table foo1 enable row level security;
ALTER TABLE

Sorry if my prior wasn't clear, but above you do 'foo' and 'foo1'
independently.

Did you intend to alter table 'foo'?

Hmm. I've clearly done both, but it still doesn't work:

rhaas=# alter table foo1 enable row level security;
ALTER TABLE
rhaas=# alter table foo1 force row level security;
ALTER TABLE
rhaas=# \d foo1
Table "public.foo1"
Column | Type | Modifiers
--------+---------+-----------
a | integer | not null
b | text |
Policies (Forced Row Security Enabled):
POLICY "hideit" FOR ALL
USING ((a < 3))
Inherits: foo

rhaas=# explain select * from foo1;
QUERY PLAN
---------------------------------------------------------
Seq Scan on foo1 (cost=0.00..22.70 rows=1270 width=36)
(1 row)

--
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

Robert,

* Robert Haas (robertmhaas@gmail.com) wrote:

On Wed, Nov 4, 2015 at 1:48 PM, Stephen Frost <sfrost@snowman.net> wrote:

* Robert Haas (robertmhaas@gmail.com) wrote:

FORCE ROW LEVEL SECURITY doesn't behave as I would expect.

rhaas=# create policy hideit on foo1 using (a < 3);
CREATE POLICY
rhaas=# explain select * from foo1;
QUERY PLAN
---------------------------------------------------------
Seq Scan on foo1 (cost=0.00..22.70 rows=1270 width=36)
(1 row)
rhaas=# alter table foo force row level security;
ALTER TABLE
rhaas=# alter table foo1 enable row level security;
ALTER TABLE

Sorry if my prior wasn't clear, but above you do 'foo' and 'foo1'
independently.

Did you intend to alter table 'foo'?

Hmm. I've clearly done both, but it still doesn't work:

rhaas=# alter table foo1 enable row level security;
ALTER TABLE
rhaas=# alter table foo1 force row level security;
ALTER TABLE
rhaas=# \d foo1
Table "public.foo1"
Column | Type | Modifiers
--------+---------+-----------
a | integer | not null
b | text |
Policies (Forced Row Security Enabled):
POLICY "hideit" FOR ALL
USING ((a < 3))
Inherits: foo

rhaas=# explain select * from foo1;
QUERY PLAN
---------------------------------------------------------
Seq Scan on foo1 (cost=0.00..22.70 rows=1270 width=36)
(1 row)

In this case, you ran it as superuser which automatically has the
'BYPASSRLS' privilege, which means that RLS is bypassed always.

The change to how BYPASSRLS works was discussed with and ultimately
implemented by Noah, as I recall.

Thanks!

Stephen

On Wed, Nov 4, 2015 at 2:39 PM, Stephen Frost <sfrost@snowman.net> wrote:

In this case, you ran it as superuser which automatically has the
'BYPASSRLS' privilege, which means that RLS is bypassed always.

The change to how BYPASSRLS works was discussed with and ultimately
implemented by Noah, as I recall.

Hmm, OK. I guess I missed the reasoning behind that decision, but
maybe it's not important.

--
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