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

From Bruce Momjian
Subject Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Date
Msg-id 200809231748.m8NHm0x16780@momjian.us
Whole thread Raw
In response to Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
Responses Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)  (Josh Berkus <josh@agliodbs.com>)
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Proposal of SE-PostgreSQL patches (for CommitFest:Sep)
Next
From: Chris Browne
Date:
Subject: Re: PostgreSQL future ideas