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: