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,
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 |