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@ak.jp.nec.com>