Re: [v9.4] row level security

2013/8/27 Greg Smith <greg(at)2ndquadrant(dot)com>:
> On 7/20/13 10:08 AM, Kohei KaiGai wrote:
>>
>> Hmm. I didn't have this idea. It seems to me fair enough and kills
>> necessity to enhance RangeTblEntry and getrelid() indeed.
>> I try to fix up this implementation according to your suggestion.
>
>
> How is that going? I'm going to do a serious review of this myself over the
> next few weeks. I have a good chunk of time set aside for it as part of a
> larger project. I'm hoping to get more people here involved in that effort
> too, starting in the November CF if that works out.
>
Sorry, I tried to rework the portions that were not graceful so much, like
system column reference or update/delete on inherited tables, however,
it eventually came back to my original implementation. :-(

The attached patch fixed the portion I was pointed out, so its overall
design has not been changed so much.

> I've been trying to catch up with your larger plan for this feature for 9.4.
> You made this comment earlier:
>
>> Also, I'd like to have discussion for this feature in earlier half of
>> v9.4 to keep time for the remaining features, such as check on
>> writer-side, integration with selinux, and so on
>
> Is any of that code around yet? I see that you have split your submissions
> so that a smaller program can be reviewed today. I'd like to start taking a
> look at the next step too though. For the project I'm starting to work on
> here, getting the integration with labeling also done is a very important
> thing to target for 9.4. It would be nice to see how that fits together
> today, even if the code for it isn't being reviewed heavily yet.
>
The biggest (and most important) portion of overall picture is this patch;
that allows to restrict rows to be visible according to pre-configured
security policy per table.
Towards label based row-level security, it needs an infrastructure to
append before-row trigger on the fly, according to row-level security
configuration, because we need a check to prevent users to write
a record with unprivileged label. It is probably annoying requirement
for users to set up triggers for each table with security policy.
Then, I'd like to offer special functions of sepgsql that shall be used
to security policy function to filter out unprivileged tuples.
On the v9.4 time-frame, I'm not certain whether we can implement
facility to manage security label of user tables.
So, I assume label based row-level security is activated when
a special named text column is defined by users.

Towards v9.5, I'd like to have a feature to add hidden column for
security label purpose on table creation time without user's
consciousness.

> I don't quite understand yet what's missing on the writer side. If you
> could help explain what's missing there, I would like to read about that.
>
It needs to back the discussion at CF-4th of v9.3. We discussed whether
we should have a special feature to check records to be inserted or
newer records to be updated, because before-row trigger can offer its
infrastructure, even though it requires users an extra configuration job
for each tables that have row-level security policy.
What I'd like to add on writer-side is an infrastructure for extensions to
inject before-row trigger functions on the tail of call-chain, that allows
to prevent records with violated values, and also allows sepgsql to
assign a default security label on new records being inserted.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>