Re: [HACKERS] FORCE ROW LEVEL SECURITY

2015-11-05 Thread Robert Haas 
On Wed, Nov 4, 2015 at 2:39 PM, Stephen Frost  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

Re: [HACKERS] FORCE ROW LEVEL SECURITY

2015-11-04 Thread Robert Haas 
On Wed, Nov 4, 2015 at 1:48 PM, Stephen Frost  wrote:
> * Robert Haas (robertmh...@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

Re: [HACKERS] FORCE ROW LEVEL SECURITY

2015-11-04 Thread Stephen Frost 
Robert,

* Robert Haas (robertmh...@gmail.com) wrote:
> On Wed, Nov 4, 2015 at 1:48 PM, Stephen Frost  wrote:
> > * Robert Haas (robertmh...@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


signature.asc
Description: Digital signature

Re: [HACKERS] FORCE ROW LEVEL SECURITY

2015-11-04 Thread Stephen Frost 
Robert,

* Robert Haas (robertmh...@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


signature.asc
Description: Digital signature

[HACKERS] FORCE ROW LEVEL SECURITY

2015-11-04 Thread Robert Haas 
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?

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

Re: [HACKERS] FORCE ROW LEVEL SECURITY

2015-11-04 Thread Stephen Frost 
* Robert Haas (robertmh...@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


signature.asc
Description: Digital signature