Re: 8.4 release planning - Mailing list pgsql-hackers

On Tue, Jan 27, 2009 at 12:41:36PM -0500, Stephen Frost wrote:
> * Gregory Stark (stark@enterprisedb.com) wrote:
> > It does seem weird to simply omit records rather than throw an error and
> > require the user to use a where clause, even if it's something like WHERE
> > pg_accessible(tab).

[…]

> do row-level security and security labels.  Requiring a where clause
> or you throw an error would certainly make porting applications that
> depend on that mechanism somewhat difficult, and doesn't really seem
> like it'd gain you all that much...

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

A

-- 
Andrew Sullivan
ajs@crankycanuck.ca