Re: Updates of SE-PostgreSQL 8.4devel patches

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, josh(at)agliodbs(dot)com, pgsql-hackers(at)postgresql(dot)org, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches
Date: 2008-10-09 01:00:21
Message-ID: 48ED57A5.3010001@ak.jp.nec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:
>> Yes, I have had similar experiences in Linux kernel development for
>> several years.
>> The amount of time to get consensus is one of the reason why I want
>> to move the SQL based row-level security to v8.5 development cycle.
>
> As I stated before, I think doing an SE-Linux version and then adding a
> more generalized solution is doing things in the wrong order because
> the generalized solution is going to have to re-do the SE-Linux stuff.
> As much as I would like to see SE-Linux support in 8.4, I think we need
> general column and row-level permission built with an eye on what
> SE-Linux will need, then add SE-Linux security.

OK, I decided to pay my efforts to implement row-level permission
as soon as possible. Its fundamental idea is same as I posted before.
It enables to assign database ACL per tuples, and enables to filter
violated tuples from the result set of query.

I guess we can see the initial working revision within the next week,
if my design was not wrong.

>> I guess he intend to share the code for row-level security, thus it
>> should be implemented prior to the OS specific feature. But most of
>> SE-PostgreSQL code is separated from core implementation and invoked
>> via security hooks, so it is unsuitable to share code with other
>> facilities.
>
> You are right based on line counts in the patch, but based on actual
> changes to the existing code, SE-Linux changes very much match what
> SQL-level permissions would need.

In my plan, the row-level permission should be mounted on the PGACE
security framework which also mounts SE-PostgreSQL.
In this way, we may be able to sat they share common codes.

> To summarize, 70% of the SE-Linux patch is in stand-alone C files, which
> has little disruption, but 30% are changes to the core backend code,
> which will be disruptive, so we would like to have SQL-level permissions
> that everyone uses to be that disruption, and have SE-Linux attach to
> those capabilities.

It is same as my design.
A new configure option enables to switch the guest of PGACE security framework,
so we will be able to choose one of SE-PostgreSQL, row-level permission and
nothing (default).

[summary of things which I have to do]
(1) To implement row-level permission (*due to the end of Oct*)
(2) To improve SE-PostgreSQL, as I have worked before
(3) To revise the documentatin/specification to wiki articles
for easily publicly accessible.

Thanks,
--
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message KaiGai Kohei 2008-10-09 01:01:12 Re: Updates of SE-PostgreSQL 8.4devel patches (r1081)
Previous Message Alvaro Herrera 2008-10-09 00:36:31 Re: [WIP] plpgsql is not translate-aware