subzerocloud / postgrest-starter-kit

Starter Kit and tooling for authoring REST API backends with PostgREST
MIT License
744 stars 71 forks source link

GRANT api TO anonymous, webuser? #61

Open ggregoire opened 3 years ago

ggregoire commented 3 years ago

Hi!

Sorry to bother with the following questions, it's probably a misunderstanding on my side.

I created a role api as you did:

-- this role will be used as the owner of the views in the api schema
-- it is needed for the definition of the RLS policies
drop role if exists api;
create role api;
grant api to current_user; -- this is a workaround for RDS where the master user does not have SUPERUSER priviliges 

Then created a policy assigned to api as you did:

-- define the who can access todo model data
-- enable RLS on the table holding the data
alter table my_table enable row level security;
-- define the RLS policy controlling what rows are visible to a particular application user
create policy my_table_access_policy on my_table to api ...

api is the owner of the corresponding view and has access to the table as you did:

alter view my_table_view owner to api;
grant select, insert, update, delete on my_table to api;

However the endpoint my_table_view returns 0 rows to webuser, although the policy allows him to see some rows. Then once I executed:

grant api to anonymous, webuser;

the endpoint and the policy worked as expected.

So my question:

You never do grant api to anonymous, webuser in this project. Is it actually needed or did I miss something?

(And I'm wondering, what's the purpose of grant api to current_user;? I saw the comment but why does master need SUPERUSER privileges to run PostgREST? And how giving api to master solves the issue since api is created without SUPERUSER privileges? I'm on RDS and I tried with both grant api to current_user; and revoke api from current_user; and I don't see a difference, but I might be missing something again)

ruslantalpa commented 3 years ago

can you post the policy body and the sample curl request (the parameters), without that i am not sure what is wrong, everything seems right (except that last grant, that is wrong).

grant api to current_user; is needed because otherwise alter view my_table_view owner to api; fails since master does not have SUPERUSER privileges to change the view owner. This grand does not relate to the flow of requests coming through postgrest, it's strictly so that alter statement succeeds;

ruslantalpa commented 3 years ago

for the full picture please also include the grants to my_table_view for anonymous and webuser