Re: FORCE ROW LEVEL SECURITY - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: FORCE ROW LEVEL SECURITY
Date
Msg-id 20151104193934.GJ3685@tamriel.snowman.net
Whole thread Raw
In response to Re: FORCE ROW LEVEL SECURITY  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: FORCE ROW LEVEL SECURITY  (Robert Haas <robertmhaas@gmail.com>)
List 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

pgsql-hackers by date:

Previous
From: Merlin Moncure
Date:
Subject: Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions
Next
From: Pavel Stehule
Date:
Subject: Re: Request: pg_cancel_backend variant that handles 'idle in transaction' sessions