Обсуждение: Row level security implementation in Foreign Table in Postgres
Row level security feature implementation in Postgres is through policy and the row security qualifier is attached as a subqueryto the main query before query planning. The RLS is implemented through ALTER TABLE STATEMENT. But my doubt is why this feature is not enabled in case of Foreign Table. (ALTER FOREIGN TABLE doesn't have a option of enablingRow Level Security). Is this is not implemented due to some limitations in the current design? Because from a quick view it looks like the security subquery can also be easily attached to the main query and passed forprocessing in foreign database. Thanks Sounak
On Wed, Nov 2, 2016 at 10:46 PM, Sounak Chakraborty <sounakr@gmail.com> wrote: > Row level security feature implementation in Postgres is through policy and the row security qualifier is attached as asubquery to the main query before query planning. The RLS is implemented through ALTER TABLE STATEMENT. > But my doubt is why this feature is not enabled in case of Foreign Table. (ALTER FOREIGN TABLE doesn't have a option ofenabling Row Level Security). > Is this is not implemented due to some limitations in the current design? > Because from a quick view it looks like the security subquery can also be easily attached to the main query and passedfor processing in foreign database. Yeah, I don't see why that couldn't be made to work. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Robert Haas <robertmhaas@gmail.com> writes:
> On Wed, Nov 2, 2016 at 10:46 PM, Sounak Chakraborty <sounakr@gmail.com> wrote:
>> But my doubt is why this feature is not enabled in case of Foreign Table. (ALTER FOREIGN TABLE doesn't have a option
ofenabling Row Level Security).
>> Is this is not implemented due to some limitations in the current design?
>> Because from a quick view it looks like the security subquery can also be easily attached to the main query and
passedfor processing in foreign database.
> Yeah, I don't see why that couldn't be made to work.
Once the patch at <30304.1478211798@sss.pgh.pa.us> gets in, the major
issue will be that FDWs will have to be careful not to select quals for
optimization (ie pushing down to a remote server) unless they satisfy
restriction_is_securely_promotable(). In most cases that should be
about a one-line change in the FDW, but I'm not sure that it'd be a good
idea to just blindly assume that FDWs are doing that. We could perhaps
add some sort of "supports RLS" flag to the FDW API, which would not
get set unless the FDW author takes positive action to do so.
regards, tom lane
Tom, all, * Tom Lane (tgl@sss.pgh.pa.us) wrote: > Robert Haas <robertmhaas@gmail.com> writes: > > On Wed, Nov 2, 2016 at 10:46 PM, Sounak Chakraborty <sounakr@gmail.com> wrote: > >> But my doubt is why this feature is not enabled in case of Foreign Table. (ALTER FOREIGN TABLE doesn't have a optionof enabling Row Level Security). > >> Is this is not implemented due to some limitations in the current design? > >> Because from a quick view it looks like the security subquery can also be easily attached to the main query and passedfor processing in foreign database. > > > Yeah, I don't see why that couldn't be made to work. > > Once the patch at <30304.1478211798@sss.pgh.pa.us> gets in, the major > issue will be that FDWs will have to be careful not to select quals for > optimization (ie pushing down to a remote server) unless they satisfy > restriction_is_securely_promotable(). In most cases that should be > about a one-line change in the FDW, but I'm not sure that it'd be a good > idea to just blindly assume that FDWs are doing that. We could perhaps > add some sort of "supports RLS" flag to the FDW API, which would not > get set unless the FDW author takes positive action to do so. That sounds like an entirely reasonable approach to me. Other than that, I agree that FDWs shouldn't be too difficult to add RLS support for as it seems pretty clear what the semantics there should be. Thanks! Stephen