Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
От | Bruce Momjian |
---|---|
Тема | Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep) |
Дата | |
Msg-id | 200809231748.m8NHm0x16780@momjian.us обсуждение исходный текст |
Ответ на | Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep) (KaiGai Kohei <kaigai@kaigai.gr.jp>) |
Ответы |
Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
|
Список | pgsql-hackers |
KaiGai Kohei wrote: > > [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. > > I reconsidered the above two options have no differences fundamentally. > > In other word, making a new enhanced security implementation based on > requirements also means making a consensus various security mechanism > can have its individual rules including guranuality of access controls. > > So, I'll decide to try to implement "fine-grained-only" security > mechanism also, because someone have such a requirememt. > However, its schedule is extremely severe, if is has to be submitted > due to the deadline of CommitFest:Nov. > > It is my hope to concentrate development of SE-PostgreSQL in v8.4 > development cycle, and I think the above "fine-grained-only" one > should be pushed to v8.5 cycle. Well, those might be your priorities, but I don't think they are the community's priorities. I think the community's priorities are to add security at the SQL level, and then we can see clearly what SE-PostgreSQL requires. This has been discussed before so it should not come as a surprise. What you can do is to do things in this order: 1) Add SE-PostgreSQL capabilities that layer over existing Postgres SQL-level permissions 2) Implement "fine-grained" permissions at the SQL level 3) Add SE-PostgreSQL capabilities for "fine-grained" permissions Perhaps you can only get #1 done for 8.4; I don't know, but I knew months ago that #2 had to be done before #3, and I think that was communicated. -- Bruce Momjian <bruce@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com + If your life is a hard drive, Christ can be your backup. +
В списке pgsql-hackers по дате отправления: