On Mon, Nov 30, 2009 at 11:03:08PM -0500, Bruce Momjian wrote: > KaiGai Kohei wrote: > > In summary, it was similar approach with what I already proposed > > in the CF#2, but rejected. > > > > During the first commit-fest of v8.5 development cycle, Stephen > > Frost suggested to rework the default PG's access controls to host > > other optional security features, not only the default one. Then, > > I submitted a large patch titled as "Reworks for Access Controls", > > but it contained 3.5KL of changeset on the core routines, and 4KL > > of new codes into "src/backend/security/*" except for > > documentations and testcases. Then, this approach was rejected > > (not "returned with feedback") due to the scale and complexity. > > > > After the fest, we discussed the direction to implement SE-PgSQL. > > Basically, it needs to keep the changeset small, and the rest of > > features (such as row-level granurality, access control decision > > cache, ...) shoule be added step-by-step consistently, according > > to the suggestion in the v8.4 development cycle. Heikki > > Linnakangas also suggested we need developer documentation which > > introduces SE-PgSQL compliant permission checks and specification > > of security hooks, after the reworks are rejected. > > > > So, I boldly removed most of the features from SE-PgSQL except for its core > > functionalities, and added developer documentation (README) and widespread > > source code comments to introduce the implementations instead. > > In the result, the current proposal is near to naked one. > > - No access controls except for database, schema, table and column. > > - No row-level granularity in access controls. > > - No access control decision chache. > > - No security OID within HeapTupleHeader. > > > > I believe the current patch is designed according to the past suggestions. > > Agreed. The patch is exactly what I was hoping to see: > > o only covers existing Postgres ACLs > o has both user and developer documentation > o includes regression tests > o main code impact is minimal
This patch addresses points 1-3 of Andrew Sullivan's post here: http://archives.postgresql.org/pgsql-hackers/2008-10/msg00388.php Left out is point 4, namely whether it's possible to map metadata access controls can do this completely, and if so, whether this patch implements such a mapping. This is totally separate from the really important question of whether SE-Linux has a future, and another about whether, if SE-Linux has a future, PostgreSQL needs to go there. All that aside, there is an excellent economic reason why a proprietary product might need to follow a dead-end technology, namely increasing shareholder value due to one or more large, long-term deals. PostgreSQL doesn't have this motive, although some of the proprietary forks may well. Can we see about Andrew Sullivan's point 4? Or is it more important to address the "do we want to" question first? Whatever order we take them in, we do need to address both. Cheers, David. -- David Fetter <da...@fetter.org> http://fetter.org/ Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter Skype: davidfetter XMPP: david.fet...@gmail.com iCal: webcal://www.tripit.com/feed/ical/people/david74/tripit.ics Remember to vote! Consider donating to Postgres: http://www.postgresql.org/about/donate -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
