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

From Simon Riggs
Subject Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
Date
Msg-id 1228762852.20796.671.camel@hp_dx2400_1
Whole thread Raw
In response to Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
Responses Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
Re: Updates of SE-PostgreSQL 8.4devel patches (r1268)
List pgsql-hackers
On Tue, 2008-12-09 at 03:33 +0900, KaiGai Kohei wrote:
> Tom Lane wrote:
> > KaiGai Kohei <kaigai@ak.jp.nec.com> writes:
> >> Bruce Momjian wrote:
> >>> I assume that could just be always enabled.
> > 
> >> It is not "always" enabled. When we build it with SE-PostgreSQL feature,
> >> rest of enhanced security features (includes the row-level ACL) are
> >> disabled automatically, as we discussed before.
> > 
> > It seems like a pretty awful idea to have enabling sepostgres take away
> > a feature that exists in the default build.
> 
> Why?
> 
> The PGACE security framework allows one or no enhanced security
> mechanism at most. It is quite natural that the default selection
> is overrided when an alternative option is chosen explicitly.

I'm finding these discussions very confusing to follow, sorry about
that.

We now have a parameter option that allows you to have row level
security in non-mandatory mode, which is good. But in order to get that
we need to build the server with a special configure option.

My previous objective was to remove the need for a configure option, so
we can enable row-level security in the default distribution of
Postgres. Are we going to enable that option in all normal distros? If
yes, why is it a configure option (at all)?

-- Simon Riggs           www.2ndQuadrant.comPostgreSQL Training, Services and Support



pgsql-hackers by date:

Previous
From: "David Rowley"
Date:
Subject: Re: Quick patch: Display sequence owner
Next
From: Tom Lane
Date:
Subject: Re: new vacuum is slower for small tables