Re: Partitioned table permission question - Mailing list pgsql-hackers

From Amit Langote
Subject Re: Partitioned table permission question
Date
Msg-id CA+HiwqHMAoXQRMhvkkQGp6Ys12BoNZZt5X4SUtMjWy08Gfg2pg@mail.gmail.com
Whole thread Raw
In response to Partitioned table permission question  (Junfeng Yang <yjerome@vmware.com>)
Responses 回复: Partitioned table permission question
List pgsql-hackers
On Tue, Apr 20, 2021 at 9:00 PM Junfeng Yang <yjerome@vmware.com> wrote:
> Hi hackers,
>
> As I played with the partitioned table with GRANT, I found two questions.
> Let's see an example:
>
>
> CREATE TABLE measurement (
>     city_id         int not null,
>     logdate         date not null,
>     peaktemp        int,
>     unitsales       int
> ) PARTITION BY RANGE (logdate);
>
> CREATE TABLE measurement_y2006m02 PARTITION OF measurement
>     FOR VALUES FROM ('2006-02-01') TO ('2006-03-01');
>
> CREATE TABLE measurement_y2006m03 PARTITION OF measurement
>     FOR VALUES FROM ('2006-03-01') TO ('2006-04-01');
>
> CREATE USER a;
> GRANT SELECT ON measurement TO a;
> GRANT INSERT ON measurement TO a;
>
> I created a partitioned table with two leaf tables and only grant SELECT, INSERT on the root table to user a.
>
> The first question is:
> As a user a, since I don't have permission to read the leaf tables, but select from the root will return the leafs
datasuccessfully.
 
>
> postgres=# set role a;
> postgres=> explain select * from measurement_y2006m02;
> ERROR:  permission denied for table measurement_y2006m02
> postgres=> explain select * from measurement;
>                                          QUERY PLAN
> ---------------------------------------------------------------------------------------------
>  Append  (cost=0.00..75.50 rows=3700 width=16)
>    ->  Seq Scan on measurement_y2006m02 measurement_1  (cost=0.00..28.50 rows=1850 width=16)
>    ->  Seq Scan on measurement_y2006m03 measurement_2  (cost=0.00..28.50 rows=1850 width=16)
> (3 rows)
>
> From the plan, we do scan on the leaf tables without ACL check. And the reason is in
expand_single_inheritance_child,
> we always set childrte->requiredPerms = 0; Seems like we always think the child has the same permission with the
partitionedtable.
 
>
>
> For the second question:
> As a user a, I'm not allowed to insert any data into leaf tables.
> But insert on the partitioned table will make the data go into leaves.
>
> postgres=> insert into measurement_y2006m02 values (1, '2006-02-01', 1, 1);
> ERROR:  permission denied for table measurement_y2006m02
> postgres=> insert into measurement values (1, '2006-02-01', 1, 1);
> INSERT 0 1
>
> It makes me feel strange, we can grant different permission for partition tables, but as long as the user
> has permission on the partitioned table, it can still see/modify the leaf tables which don't have permission.
> Can anyone help me understand the behavior?

Permission model of partitioning is same as traditional table
inheritance, about which we write the following in the documentation
[1]:

"Inherited queries perform access permission checks on the parent
table only. Thus, for example, granting UPDATE permission on the
cities table implies permission to update rows in the capitals table
as well, when they are accessed through cities. This preserves the
appearance that the data is (also) in the parent table. But the
capitals table could not be updated directly without an additional
grant. In a similar way, the parent table's row security policies (see
Section 5.8) are applied to rows coming from child tables during an
inherited query. A child table's policies, if any, are applied only
when it is the table explicitly named in the query; and in that case,
any policies attached to its parent(s) are ignored."

-- 
Amit Langote
EDB: http://www.enterprisedb.com

[1] https://www.postgresql.org/docs/current/ddl-inherit.html



pgsql-hackers by date:

Previous
From: Julien Rouhaud
Date:
Subject: Typo in dshash_find() comments
Next
From: Magnus Hagander
Date:
Subject: Re: when the startup process doesn't