Re: 8.4 release planning - Mailing list pgsql-hackers

Tom Lane wrote:
> Joshua Brindle <method@manicmethod.com> writes:
>> Tom Lane wrote:
>>> Right, which is why it's bad for something like a foreign key constraint
>>> to expose the fact that the row does exist after all.
> 
>> Once again, this is not an issue for us.
> 
> Yes it is an issue; claiming it isn't doesn't make it so.  You just
> stated, in effect, that you don't implement data hiding in the
> filesystem because it would break standard Unix filesystem semantics.

We break plenty of standard semantics. Applications generally expect to be able 
to unlink files they can write to, to truncate or append. They expect 
read()/write() calls to succeed after a successful open(). SELinux is more fine 
grained than POSIX/UNIX is so some of these fundamental assumptions got broken.

In the end this created better/safer software, after some growing pains of course.

> How is that consistent with your opinion that it's okay to break
> standard SQL semantics in order to implement data hiding in a database?
> 

Please step me through how the SQL semantics are being broken.
From my perspective (I've used databases, written applications for them, etc 
but never hacked on a database server directly) this seems pretty straightforward.

There already exists the possibility that you won't be able to read/write one or 
more of the tables for which a foreign key constraint exists, how do you handle 
it now? Why isn't it appropriate to handle it the same way?

> The question of whether there is a covert channel is only a small part
> of my complaint here.  If it's the judgement of security experts that
> that's an acceptable thing, that's fine, it's their turf.  But SQL
> behavior is my turf, and I'm not happy with discarding fundamental
> semantic properties.
> 
> Quoting from your other message:
> 
>> We do not consider that a short coming, anyone who needs to hide
>> existence of files needs to set up their directory structure to
>> disallow read/search/create on the directories they aren't allowed to
>> discover filenames in.
> 
> This seems to me to be exactly parallel to deciding that SELinux should
> control only table/column permissions within SQL; an approach that would
> be enormously less controversial, less expensive, and more reliable than
> what SEPostgres tries to do.
> 

It isn't parallel though, in applications using the filesystem specifying 
directories where files go is fairly common. In database applications you expect 
all the data to be in the same table, having multiple tables with the same 
schema to try and separate out data that should be visible to some and not 
others isn't acceptable to most people and certainly wouldn't be compatible with 
many existing applications.

Further, we have the ability to use per-process namespaces/polyinstantiation on 
the filesystem. From what I've heard that is somewhere you are unwilling to go 
as a community for postgresql so the options are somewhat more limited.

I'm not trying to pretend that SELinux and sepostgresql are the same thing and 
always have to be treated the same. The trusted X work uses the same 
infrastructure and security policy language as sepostgres and selinux itself but 
noone is comparing windows and pointers to tables and rows.

Type enforcement is a flexible system. You identify the objects that are 
important to you in the object manager (postgresql in this case) and assign 
types to it and write policies around those types. The SELinux community came to 
a consensus quite a while back about what objects were important to us. I had 
assumed (perhaps foolishly) that this had been communicated and also agreed upon 
in the postgresql community.

If that wasn't the case I hope we can sit down and talk about the model to 
determine what objects are important to everyone and talk about the 
implementation details afterward.