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: