From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Haribabu Kommi <kommi(dot)haribabu(at)gmail(dot)com> |
Cc: | Stephen Frost <sfrost(at)snowman(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Joe Conway <mail(at)joeconway(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Multi-tenancy with RLS |
Date: | 2016-01-07 07:42:02 |
Message-ID: | 568E16CA.3070603@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016/01/07 15:25, Haribabu Kommi wrote:
> On Thu, Jan 7, 2016 at 4:31 PM, Amit Langote
> <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> wrote:
>>
>> I applied all the patches. I have a basic question. Sorry though if I've
>> entirely missed the point (and/or scope) of your proposal. I wonder if
>> something like the following should not have failed with the patch:
>>
>> postgres=# CREATE POLICY class_policy ON pg_class TO PUBLIC USING
>> (relowner = current_user);
>> ERROR: permission denied: "pg_class" is a system catalog
>>
>> Is there no support yet for user-defined catalog policies?
>
> Currently the patches don't have the support of allowing user to
> create policies on catalog tables. The policies similar like you
> specified are prepared for all eligible catalog tables and those
> will be used when the user enables the catalog security.
>
> Presently, default policies are used to provide proper multi-tenancy
> behavior. May be we can add the support of user to update the
> existing policies and add new policies on the catalog tables
> without dropping the creation of default polices, as these are
> required for supporting multi-tenancy by default without any
> user policies.
Okay. Thanks for explaining.
> Example usage:
>
> postgres=# create role test_user1;
> CREATE ROLE
> postgres=# create role test_user2;
> CREATE ROLE
> postgres=# alter database postgres with catalog security true;
> ALTER DATABASE
> postgres=# set session authorization test_user1;
> SET
> postgres=> create table tbl1(f1 int);
> CREATE TABLE
> postgres=> set session authorization test_user2;
> SET
> postgres=> create table tbl2(f2 int);
> CREATE TABLE
> postgres=> \d
> List of relations
> Schema | Name | Type | Owner
> --------+------+-------+------------
> public | tbl2 | table | test_user2
> (1 row)
Okay, so the patch's system-defined policy seems enough to achieve this
much isolation.
By the way, if test_user2 had created a table with the same name, it would
produce the following error:
ERROR: relation "tbl1" already exists
So, certain information (relname in this case) is bound to be leaked here
because syscache look-ups don't abide by catalog RLS. But I guess hoping
that it would may be being overly paranoid and if pursued at all, an
entirely separate project.
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Paquier | 2016-01-07 07:42:09 | Re: extend pgbench expressions with functions |
Previous Message | Pavel Stehule | 2016-01-07 07:12:55 | Re: Add numeric_trim(numeric) |