Re: 8.4 release planning - Mailing list pgsql-hackers

From Joshua D. Drake
Subject Re: 8.4 release planning
Date
Msg-id 1233018149.6617.119.camel@jd-laptop.pragmaticzealot.org
Whole thread Raw
In response to Re: 8.4 release planning  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: 8.4 release planning
List pgsql-hackers
On Mon, 2009-01-26 at 19:21 -0500, Tom Lane wrote:

> 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.

It was only today that I saw an announcement go out to our announce list
to try and get people to pop their heads up and help. It looks like
today is the day that someone actually reached out to the SELinux folks
and asked for help. We really aren't very good at reaching out for help.
We have a tendency to stick to our little pods, in this case -hackers.

> 
> 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.

I think this is a fair statement to make. I would also note that at
least one other SELinux person has offered today to review at least the
SE portions of this. I quote:

"
Yes, I will look at them to the extent I am able. As I am not familiar
with the postgresql codebase I won't be able to assert the correctness
of the hook placement (that is, where the security functions are called
with respect to the data they are protecting being accessed). The
postgresql community should be more familiar with the hook call sites
and hopefully can assist there.

I should be able to handle the security backend and determining whether
it matches the security model we agreed on, but the hook placement is
just as important since a misplaced or missing hook will allow access
that should not be granted.

Joshua Brindle
"

I do think its important to recognize that SEPostgres is a specialty
feature. Like full disjunctions was, it is a feature that very, very few
will use but those that do really do want and will very much make use of
it.

If I put on my pragmatic helmet it is a high cost, low benefit feature
for the vast majority of our community.

If I put on my advocacy hat it is a, "Hah take that you little blue
mammal!" and frankly "There is no big O in this equation... if you want
this kind of power you gotta ride the elephant!".

There is a strategic element though. Adding features for the too smart
for their own good lures the too smart for their own good to use (and
enhance) a product. This could help us in the long run.

Sincerely,

Joshua D. Drake


-- 
PostgreSQL - XMPP: jdrake@jabber.postgresql.org  Consulting, Development, Support, Training  503-667-4564 -
http://www.commandprompt.com/ The PostgreSQL Company, serving since 1997
 



pgsql-hackers by date:

Previous
From: Rick Vernam
Date:
Subject: Re: 8.4 release planning
Next
From: Tom Lane
Date:
Subject: Re: 8.4 release planning