Re: SE-PgSQL patch review

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 <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778 AIM: dfetter666 Yahoo!: dfetter
Skype: davidfetter XMPP: david(dot)fetter(at)gmail(dot)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