Re: SE-PostgreSQL and row level security - Mailing list pgsql-hackers

From BogDan Vatra
Subject Re: SE-PostgreSQL and row level security
Date
Msg-id 1782.79.117.220.208.1234379559.squirrel@omnidatagrup.ro
Whole thread Raw
In response to SE-PostgreSQL and row level security  ("BogDan Vatra" <taipan@omnidatagrup.ro>)
Responses Re: SE-PostgreSQL and row level security
List 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,






pgsql-hackers by date:

Previous
From: Gianni Ciolli
Date:
Subject: Re: HotStandby vs. flatfile updates
Next
From: Alvaro Herrera
Date:
Subject: Re: Re: [COMMITTERS] pgsql: Update autovacuum to use reloptions instead of a system catalog,