Re: SE-PostgreSQL and row level security

From: "BogDan Vatra" <taipan(at)omnidatagrup(dot)ro>
To: "KaiGai Kohei" <kaigai(at)ak(dot)jp(dot)nec(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: SE-PostgreSQL and row level security
Date: 2009-02-11 19:12:39
Message-ID: 1782.79.117.220.208.1234379559.squirrel@omnidatagrup.ro
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,
[...]
>
> In my understanding, the row-level ACLs feature (plus a bit enhancement)
can
> help your requirements. I developed it with SE-PostgreSQL in parallel,
but also postponed to v8.5 series.
> It enables to assign database ACLs on individual tuples, and filter out
violated tupled from the result set of SELECT, UPDATE and DELETE.
>
> So, it is not very hard. At least, we already have an implementation. :)

Where is it ? I like to try it? If is working why is not included in 8.4?
IMHO this is a killer feature. I like to try this, and if you want I like
to give you more feedbacks.

[..]
>
> I guess you concerned about:
> - It is necessary to set up many trigger functions for each tables, which
> provide similar functionality.
> - Users have to specify different names between reference and
> modification.
>
> And, you want to make clear how the row-level access control resolves
it. Is it OK?

Yes.

>
> Your requirement is a simple separation between different users. Thus,
what we have to do is:
> - When a tuple is inserted, the backend automatically assigns an ACL
> which
> allows anything for the current user, but nothing for others.
> - So, when user tries to select, update and delete this table, tuples
> which
> inserted by others to be filtered out from the result set or affected
> rows.
> - Normal users are disallowed to change automatically assigned ACLs.
> (I don't think you want to restrict superuser's operations.)
>
> The row-level ACLs have a functionality named as "default acl".
> It enables table's owner to specify ACLs to be assigned to newly
inserted tuple, like:
>
> CREATE TABLE customer_products (
> id serial,
> :
> ) WITH (default_row_acl='{rwd=kaigai}');
>
> Currently, it does not allow replacement rules like
"{rwd=%current_user}", but it is not a hard enhancement. If such an ACL
is assigned, the tuple is not visible from other users without any
triggers.
>
> For example, please consider when a user "kaigai" insert a tuple into
"customer_products", the "{rwd=kaigai}" is assigned to the tuple, but
the "{rwd=bogdan}" is assigned when a user "bogdan" do same thing.
>
> In this case, any users must not be an owner of the table, because owner
of the table is allowed to change the ACLs.
>
> This is an aside. If you want different access controls, like read-only
for other's tuples but read-writable for own tuples, it will be possible
with different default acl configuration.
>
> Does it help you to understand about the row-level security currently we
are in development?
>

Yes and I like to try it (with more complex situations).
I have C/C++ knowledge maybe I can help you with this.

BIG TANKS
BogDan,

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2009-02-11 19:12:43 Re: Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,
Previous Message Gianni Ciolli 2009-02-11 18:48:02 Re: HotStandby vs. flatfile updates