Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep) - Mailing list pgsql-hackers

From KaiGai Kohei
Subject Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Date
Msg-id 48D31747.3030304@ak.jp.nec.com
Whole thread Raw
In response to Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Responses Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  ("Robert Haas" <robertmhaas@gmail.com>)
Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
List 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.
Itwould be hard to explain> that PostgreSQL does not have column-level GRANT privileges but that you> can achieve the
sameif 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
itsscope
 

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


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Common Table Expressions (WITH RECURSIVE) patch
Next
From: "Jeffrey Baker"
Date:
Subject: 8.3.1 autovacuum stopped doing anything months ago