Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)

From: KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>
Cc: pgsql-hackers(at)postgresql(dot)org, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
Subject: Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Date: 2008-09-19 03:06:47
Message-ID: 48D31747.3030304@ak.jp.nec.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At the CommitFest:Sep, I got several comments about SE-PostgreSQL from Peter.
(Thanks for your comments.)
He asked me several questions about its concept, then I replied for them.
However, it seems to me there is a difference in our opinions.

In my opinion, it is quite natural that different security mechanisms can
have differences in its decision making, its gulanuality and its scope.
But he concerned that SE-PostgreSQL provides fine-grained access control
feature, though the native PostgreSQL does not provide it yet.

> *) Row-level security, column-level security and so on should in my mind
> first exist as a native SQL-level feature. It would be hard to explain
> that PostgreSQL does not have column-level GRANT privileges but that you
> can achieve the same if you go through SELinux.

I don't know his current opinion.
But I think it is not worthful to stop making a progress due to
differences in opinions. So, I think there are the following three
options to solve the issue.

[1] Make a consensus that different security mechanisms have differences
in its decision making, its gulanuality and its scope

I think it is the most straightforward answer.
As operating system doing, DAC and MAC based access controls should be
independently applied on accesses from users, and this model is widely
accepted.
These facilities can also have different results, gulanualities and scopes.

[2] Make a new implementation of OS-independent fine grained access control

If it is really really necessary, I may try to implement a new separated
fine-grained access control mechanism due to the CommitFest:Nov.
However, we don't have enough days to develop one more new feature from
the scratch by the deadline.

[3] Restrict functionalities of SE-PostgreSQL

It is the most laughable idea.
If SE-PostgreSQL lose its fine-grained access control feature, both of
access control features have same gulanualities at least.
But it makes unmotivate me so much. I believe no one agree this option.

I want any comments on this topic.
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 Jeffrey Baker 2008-09-19 04:23:34 8.3.1 autovacuum stopped doing anything months ago
Previous Message Tom Lane 2008-09-19 02:52:31 Re: Common Table Expressions (WITH RECURSIVE) patch