Re: 8.4 release planning - Mailing list pgsql-hackers

From KaiGai Kohei
Subject Re: 8.4 release planning
Date
Msg-id 497E6D87.90703@ak.jp.nec.com
Whole thread Raw
In response to Re: 8.4 release planning  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
Tom Lane wrote:
> Stephen Frost <sfrost@snowman.net> writes:
>> * Tom Lane (tgl@sss.pgh.pa.us) wrote:
>>> The problem, in words of one syllable, is that we are not sure we want
>>> it.  Do you see a user community clamoring for SEPostgres, or a hacker
>>> community that is willing or able to maintain it?
> 
>> No, it doesn't have as large a user base as the Windows port or
>> integrated text search.  On the other hand, there *are* users out there,
>> and hackers, who are willing and interested in it for PostgreSQL because
>> it would give them an alternative to the de-facto standards.
> 
> Then why has *nobody* stepped up to review the design, much less the
> whole patch?  The plain truth is that no one appears to care enough to
> expend any real effort.  But this patch is far too large and invasive
> to accept on the basis that only one guy understands it and will/might
> continue to maintain it.

The matter we're currently faced can be called as like a disconnection
between OSS communities.
At least, as several folks introduced in this thread, security focused
people are strongly waiting for SE-PostgreSQL feature upstreamed.
However, we have a wall to be overed, if they join to review the patches,
because most of security experts are not database experts (familiar to
its internal architectures).

In addition, I have hesitated to involve security experts due to the
discussion will need deep knowledge about its internal architectures.
But I think Bruce's suggestion is whorthwhile. At least, it is a case
we need cross-community discussion.

> I'll risk being rude to make my point: those who want SEPostgres in core
> need to put up or shut up.  Now, not at some future time.  We need
> people to sign off that this patch implements the features they want
> (not "sounds roughly like some vague future need I might have") and does
> so correctly.  An incorrect security feature is considerably worse than
> useless.  And once it's in core we aren't going to have a whole lot of
> elbow room to change the definition later.

At least, the security design of SE-PostgreSQL has been accepted for
two years in SELinux community. An evidence is its upstreamed security
policy (reference policy) contains rules for SE-PostgreSQL.
 http://oss.tresys.com/repos/refpolicy/trunk/policy/modules/services/postgresql.te

Thanks,
-- 
OSS Platform Development Division, NEC
KaiGai Kohei <kaigai@ak.jp.nec.com>


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: 8.4 release planning
Next
From: KaiGai Kohei
Date:
Subject: Re: 8.4 release planning