Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
От | KaiGai Kohei |
---|---|
Тема | Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep) |
Дата | |
Msg-id | 48D31747.3030304@ak.jp.nec.com обсуждение исходный текст |
Ответ на | Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep) (KaiGai Kohei <kaigai@ak.jp.nec.com>) |
Ответы |
Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep) |
Список | 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 по дате отправления: