Re: [PATCH] SE-PgSQL/tiny rev.2193 - Mailing list pgsql-hackers

From Joshua Brindle
Subject Re: [PATCH] SE-PgSQL/tiny rev.2193
Date
Msg-id 4A64C3A1.4040303@manicmethod.com
Whole thread Raw
In response to Re: [PATCH] SE-PgSQL/tiny rev.2193  (Peter Eisentraut <peter_e@gmx.net>)
Responses Re: [PATCH] SE-PgSQL/tiny rev.2193  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
Peter Eisentraut wrote:
> On Monday 20 July 2009 21:05:38 Joshua Brindle wrote:
>> How many people are you looking for? Is there a number or are you waiting
>> for a good feeling?
>
> In my mind, the number of interested people is relatively uninteresting, as
> long as it is greater than, say, three.
>
> What is lacking here is a written specification.
>
> When it comes to larger features, this development group has a great deal of
> experience in implementing existing specifications, even relatively terrible
> ones like SQL or ODBC or Oracle compatibility.  But the expected behavior has
> to be written down somewhere, endorsed by someone with authority.  It can't
> just be someone's idea.  Especially for features that are so complex,
> esoteric, invasive, and critical for security and performance.
>

Who do you consider has authority? The security community has as many opinions 
as any other. There are papers written on mandatory access controls in rdbms's 
but they are mostly about multi-level security, which SELinux has but primarily 
uses type enforcement. The SELinux community are all on board with KaiGai's 
object model (the object classes and permissions and how they are enforced), 
there has been quite a bit of discussion about them over the years. Trusted 
RUBIX integrated SELinux using the object classes that KaiGai made for SEPostgres.

> So I think if you want to get anywhere with this, scrap the code, and start
> writing a specification.  One with references.  And then let's consider that
> one.
>

Harsh.


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: [GENERAL] pg_migrator not setting values of sequences?
Next
From: Tom Lane
Date:
Subject: Re: [PATCH v4] Avoid manual shift-and-test logic in AllocSetFreeIndex