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 <[EMAIL PROTECTED]>

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to