On Tue, Oct 6, 2015 at 10:56 AM, Haribabu Kommi <kommi.harib...@gmail.com> wrote: > Here I attached an updated version of the patch with the following changes.
I found some problems related to providing multi-tenancy on a system catalog view. This is because, system catalog view uses the owner that is created the user instead of the current user by storing the user information in "checkAsUser" field in RangeTblEntry structure. The same "checkAsUser" is used in check_enable_rls function before getting the policies for the table. All the system catalog views are created by the super user, so no row level security policies are applied to the views. Ex- SET SESSION ROLE tenancy_user1; select relname from pg_class where relname = 'tenancy_user2_tbl1'; relname --------- (0 rows) select schemaname, relname from pg_stat_all_tables where relname = 'tenancy_user2_tbl1'; schemaname | relname ------------+-------------------- public | tenancy_user2_tbl1 (1 row) The policy that is created on pg_class system catalog table is, get all the objects that current user have permissions. Permissions can be anything. To fix the problem, I thought of using current session id instead of "checkAsUser" while applying row level security policies to system catalog objects. This doesn't affect the normal objects. But this solution has given some problems for foreign_data.sql while running the regress tests as the planner is generating targetlist as NULL. Is the above specified solution is the correct approach to handle this problem? If it is i will check the foreign_data.sql problem, otherwise is there any good approach to handle the same? Regards, Hari Babu Fujitsu Australia -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers