Re: 8.4 release planning

From: Stephen Frost <sfrost(at)snowman(dot)net>
To: Andrew Sullivan <ajs(at)crankycanuck(dot)ca>, pgsql-hackers(at)postgresql(dot)org
Cc: Joshua Brindle <method(at)manicmethod(dot)com>
Subject: Re: 8.4 release planning
Date: 2009-01-27 19:15:06
Message-ID: 20090127191506.GO8123@tamriel.snowman.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Andrew,

* Andrew Sullivan (ajs(at)crankycanuck(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2009-01-27 19:18:12 Re: 8.4 release planning
Previous Message Heikki Linnakangas 2009-01-27 19:13:41 Re: pg_upgrade project status