Search Postgresql Archives

Re: GRANTable Row Permissions

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Of course I think of something as soon as I send it.  Policies can be
granted to a specific role! So

   create policy xxxxxx on table_1 for select to role_1 using (row_id = 1234);

Jim

On Sun, Jul 3, 2016 at 12:26 PM, James Keener <jim@xxxxxxxxxxxxx> wrote:
> I'm trying to work out how to grant permissions to rows in a table
> without having to rebuild the pg auth mechanisms (see below). One option
> is to have many tables (each representing a row), and grant normally.
> The other is, like I build below, uses a table and a recursive CTE to
> resolve the PG group membership and apply it to the table in question
> using a RLS policy.  Is any of this sane?
>
> So, aay I have
>
>     create table viz (
>         viz_id bigserial primary key,
>         name text
>     );
>
>     create role group_a;
>     create role group_b;
>     create role user1;
>     create role user2;
>     create role user3;
>
>     grant group_a to user1;
>     grant group_b to group_a;
>
>     insert into viz (name) values ('test 1'),('test 2'),('test 3');
>
>
>
> I am trying to find a way to essentially do the following:
>
>         revoke select on viz from public;
>         grant select on viz to group_a where viz_id = 1;
>         grant select on viz to user2 where viz_id = 2;
>         grant select on viz to group_b where viz_id = 3;
>
> With RLS I can create a policy that can validate via an arbitrary sql
> statement, but I can't think of a clean way to have row-level grants
> that can be implemented without having to kludge the pg permission
> system into a table.  The following kind of gets at what I want, but
> uses a table instead of being able to grant.
>
>     create table viz_perm (
>         viz_id bigint references viz,
>         role_name text,
>         can_view boolean not null default false
>     );
>
>     alter table viz enable row level security;
>     alter table viz_perm enable row level security;
>
>     create policy viz_permissions on viz_perm for select using (
>         (with recursive rec_roles(grantee,granted) as (
>         select roless.rolname as grantee, groupss.rolname as granted
>         from pg_roles roless
>         inner join pg_auth_members
>             on roless.oid = pg_auth_members.member
>         inner join pg_roles groupss
>             on groupss.oid = pg_auth_members.roleid
>         union
>         select rec_roles.grantee as grantee, groupss.rolname as granted
>         from rec_roles
>         inner join pg_roles roless on roless.rolname = rec_roles.granted
>         inner join pg_auth_members
>             on roless.oid = pg_auth_members.member
>         inner join pg_roles groupss
>             on groupss.oid = pg_auth_members.roleid
>         )
>         select bool_or(true)
>         from rec_roles
>         where
>         role_name = current_user
>          or (grantee = current_user and granted = role_name))
>     );
>
>      create policy viz_permissions on viz using (
>          (select bool_or(can_view)
>           from viz_perm
>           where viz_perm.viz_id=viz.viz_id)
>      );
>
>     insert into viz_perm (viz_id, role_name, can_view) values
>         (1, 'group_a', true),
>         (2, 'user2',   true),
>         (3, 'group_b', true);
>
>     grant select on viz to user1;
>     grant select on viz_perm to user1;
>     grant select on viz to user2;
>     grant select on viz_perm to user2;
>
>
>     set role user1;
>     select * from viz;
>     -- viz_id |  name
>     ----------+--------
>     --      1 | test 1
>     --      3 | test 3
>     --(2 rows)
>
>     reset role;
>     set role user2;
>     select * from viz;
>     -- viz_id |  name
>     ----------+--------
>     --      2 | test 2
>     --(1 row)
>
>     reset role;
>
> While the above more-or-less works, it feels very wonky.  Is there a
> better way to do this? Would it be better to have a table for each viz,
> necessitating each table having a single row, and using the standard
> permission system.  Is what I describe and build in this email an
> acceptable way to go about doing what I want to do?
>
> Thanks,
> Jim


-- 
Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general



[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux