Re: [HACKERS] RLS policy not getting honer while pg_dump ondeclarative partition - Mailing list pgsql-hackers

From Amit Langote
Subject Re: [HACKERS] RLS policy not getting honer while pg_dump ondeclarative partition
Date
Msg-id 6c7d3005-01c6-f111-18d6-647a7043337c@lab.ntt.co.jp
Whole thread Raw
In response to Re: [HACKERS] RLS policy not getting honer while pg_dump ondeclarative partition  (Stephen Frost <sfrost@snowman.net>)
Responses Re: [HACKERS] RLS policy not getting honer while pg_dump ondeclarative partition
List pgsql-hackers
On 2017/06/17 9:20, Stephen Frost wrote:
> Greetings,
> 
> * Rushabh Lathia (rushabh.lathia@gmail.com) wrote:
>> While doing some testing I noticed that RLS policy not getting honer
>> while pg_dump on declarative partition.
>>
>> I can understand that while doing SELECT on individual child
>> table, policy of parent is not getting applied. But is this desirable
>> behaviour? I think for partitions, any policy on the root table should
>> get redirect to the child, thoughts?
>>
>> If current behaviour is desirable then atleast we should document this.
> 
> The current behaviour matches how the GRANT system works, unless it's
> been changed as part of the partitioning patches, we don't check the
> privileges on tthe parent to see if an individual has access to the
> child.

The partitioning patch itself (either f0e44751d71 or any subsequent
patches) didn't change any of how that works.  One would get the same
behavior as one would with inheritance, as described in the inheritance
section:

https://www.postgresql.org/docs/devel/static/ddl-inherit.html

"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.7) 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."

> I think we could certainly consider if this behavior is desirable in a
> system which includes partitioning instead of inheritance,

Do we want CREATE POLICY foo ON parent creating the policy objects for all
the partitions?  That is, cascade the policy object definition?

> but if we
> wish to do so then I think we should be considering if the GRANT system
> should also be changed as I do feel the two should be consistent.

IIUC, you are saying here that GRANT should be taught to cascade the
permission grant/revokes to partitions.


Also, the somewhat related nearby discussion about dumping the partition
data through the root parent will perhaps have to think about some of
these things.  Dumping data through the root table will take care of the
problem that Rushabh is complaining about, because only rows visible per
the parent's policies would be dumped.  Of course then the the set of rows
dumped will be different from what it is today, because one would expect
that a different set of policies would get applied - the root table's
policies when dumping data through it vs. the individual partitions'
policies when dumping data per partition.

Thanks,
Amit




pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Refreshing subscription relation state inside atransaction block
Next
From: Dean Rasheed
Date:
Subject: [HACKERS] Rules on table partitions