On Tue, Oct 6, 2015 at 10:56 AM, Haribabu Kommi
<kommi.haribabu@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