| From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
|---|---|
| To: | Andrea Adami <fol(at)fulcro(dot)net> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: CREATE POLICY bug ? |
| Date: | 2016-08-20 14:01:40 |
| Message-ID: | CAEZATCXA27WT6pr4HX5b_-rqSLQgbXC31fjDZ++9VJjTFncC9w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 20 August 2016 at 03:15, Andrea Adami <fol(at)fulcro(dot)net> wrote:
> when i run the query: "select * from public.policy_view"
> the ouput is the same (all rows) for all users
> i'm doing some mistakes or this is a bug ?
>
No, it looks correct to me. When going through a view, the policies
and permission checks that apply are those that would apply to the
view's owner, which in this case is postgres, so no policies are
applied.
Or, quoting from the notes in the CREATE POLICY documentation:
As with normal queries and views, permission checks and policies for
the tables which are referenced by a view will use the view owner's
rights and any policies which apply to the view owner.
Regards,
Dean
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Petr Jelinek | 2016-08-20 14:04:38 | Re: Logical decoding slots can go backwards when used from SQL, docs are wrong |
| Previous Message | Craig Ringer | 2016-08-20 14:01:02 | Re: Logical decoding slots can go backwards when used from SQL, docs are wrong |