Re: 8.4 release planning - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: 8.4 release planning
Date
Msg-id 20090127191506.GO8123@tamriel.snowman.net
Whole thread Raw
In response to Re: 8.4 release planning  (Andrew Sullivan <ajs@crankycanuck.ca>)
List pgsql-hackers
Andrew,

* Andrew Sullivan (ajs@crankycanuck.ca) wrote:
> Throwing an error would entail a side-channel leak that would not be
> acceptable to the security community, I bet.  That said, I have
> reservations, along the lines of Peter E's, that the early
> design-level objections to the approach were never answered.  I
> certainly never got any real answer to questions I asked, for what
> it's worth.

I've added Joshua Brindle (hope that's alright, Josh), since I'm not sure
if he's trying to follow this whole 'release planning' thread and your
concerns are regarding SE-PostgreSQL.  I hope he can help to address
them (below).

> I will note that I tried to have a look at the literature on this
> topic.  As I started to read, it became obvious that it was copious,
> but pretty well-determined.  What bothered me most about the answers I
> got was that there never seemed to be an answer to "please outline the
> design principles" except for "it's what SE-Linux does".  The OS-level
> control rules seemed to me to be totally foreign to the database
> world, precisely because ACID is a problem in databases in a way it
> isn't for filesystems under the traditional UNIX model.  I formed the
> impression -- only an impression, mind, that there was a poor fit
> between SE-Linux and database systems, and that the proponents had
> decided that enough caulk (in the form of "don't do that") would seal
> the gap.
>
> I haven't (obviously) been paying much attention to this topic since,
> but I detect something of the same sort of response in the recent
> discussion.  Maybe the goal isn't explicit enough.  If the goal is
> compliance with some set of well-defined tests, what are they?  If the
> goal is buzzword compliance, what are the tests of that (to the extent
> there ever are some)?  If the goal is just "security enhancement", I
> confess that I am still unable to understand the definitions of
> "security" and "enhancement" such that I think we have some
> operationalization of what the patch is supposed to provide.
>
> I know there are people who think this is cool.  I guess, if I were
> running the circus, I'd want to know what's cool about it, and why.
> Then maybe the project would be in a position to understand whether
> that kind of cool is the way it wants to be.  But without a clear
> problem statement, and a roadmap of how the patches solve the problem,
> I'm at a loss.  And last I checked (which was, admittedly, not today),
> the project pages didn't have that information.
Thanks,
    Stephen

pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: pg_upgrade project status
Next
From: Tom Lane
Date:
Subject: Re: 8.4 release planning