Skip site navigation (1) Skip section navigation (2)

Re: Updates of SE-PostgreSQL 8.4devel patches

From: Bruce Momjian <bruce(at)momjian(dot)us>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches
Date: 2008-09-26 22:15:46
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Tom Lane wrote:
> "Robert Haas" <robertmhaas(at)gmail(dot)com> writes:
> > I think you have to resign yourself to the fact that a user who can
> > see only a subset of the rows in a table may very well see apparent
> > foreign-key violations.  But so what?
> So you're leaking information about the rows that they're not supposed
> to be able to see.  This is not what I would call national-security-grade
> information hiding --- leastwise *I* certainly wouldn't store nuclear
> weapon design information in such a database.  The people that the NSA
> wants to defend against are more than smart enough, and persistent
> enough, to extract information through such loopholes.
> I can't escape the lurking suspicion that some bright folk inside the
> NSA have spent years thinking about this and have come up with some
> reasonably self-consistent definition of row hiding in a SQL database.
> But have they published it where we can find it?

I am confused how knowing that a sequence number used for a primary key
exists or doesn't exist is leaking _meaningful_ information.  People
might know the sequence number exists, but how is that information
useful.  Now, if natural keys are used, that is a different story.

I am, of course, supportive of digging deeper to find the best possible
behavior.  I am also supportive of making row-level security an
SQL-level feature that can be used beyond SE-Linux, and will allow the
feature to be tested on all platforms.

  Bruce Momjian  <bruce(at)momjian(dot)us>

  + If your life is a hard drive, Christ can be your backup. +

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2008-09-26 22:23:30
Subject: Re: parallel pg_restore - WIP patch
Previous:From: Bruce MomjianDate: 2008-09-26 22:11:14
Subject: Re: Updates of SE-PostgreSQL 8.4devel patches

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group