Re: Updates of SE-PostgreSQL 8.4devel patches (r1710) - Mailing list pgsql-hackers

From Alvaro Herrera
Subject Re: Updates of SE-PostgreSQL 8.4devel patches (r1710)
Date
Msg-id 20090311135413.GG4009@alvh.no-ip.org
Whole thread Raw
In response to Re: Updates of SE-PostgreSQL 8.4devel patches (r1710)  (Gregory Stark <stark@enterprisedb.com>)
Responses Re: Updates of SE-PostgreSQL 8.4devel patches (r1710)  (Ron Mayer <rm_pg@cheapcomplexdevices.com>)
Re: Updates of SE-PostgreSQL 8.4devel patches (r1710)  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: Updates of SE-PostgreSQL 8.4devel patches (r1710)  (KaiGai Kohei <kaigai@ak.jp.nec.com>)
Re: Updates of SE-PostgreSQL 8.4devel patches (r1710)  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
Gregory Stark escribió:
> Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
> 
> > KaiGai Kohei wrote:
> >>  * ACL_SELECT_FOR_UPDATE has same value with ACL_UPDATE, so SE-PostgreSQL
> >>    checks db_table:{update} permission on SELECT ... FOR SHARE OF,
> >>    instead of db_table:{lock} permission.
> >
> > This again falls into the category of trying to have more fine-grained
> > permissions than vanilla PostgreSQL has. Just give up on the lock permission,
> > and let it check update permission instead. Yes, it can be annoying that you
> > need update-permission to do SELECT FOR SHARE, but that's an existing problem
> > and not in scope for this patch.
> 
> Would it make sense to instead of removing and deferring pieces bit by bit to
> instead work the other way around? Extract just the part of the patch that
> maps SELinux capabilities to Postgres privileges as a first patch? Then
> discuss any other parts individually at a later date? 

I think that makes sense.  Implement just a very basic core in a first
patch, and start adding checks slowly, one patch each.  We have talked
about "incremental patches" in the past.

We wouldn't get "unbreakable PostgreSQL" in a single commit, but we
would at least start moving.

The good thing about having started in the opposite direction is that by
now we know that the foundation APIs are good enough to build the
complete feature.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.


pgsql-hackers by date:

Previous
From: Marko Kreen
Date:
Subject: Re: gcc: why optimize for size flag is not the default
Next
From: Simon Riggs
Date:
Subject: Re: idea, proposal: only preloadable libraries (conditional load)