Re: SE-PostgreSQL Specifications - Mailing list pgsql-hackers

From Chris Browne
Subject Re: SE-PostgreSQL Specifications
Date
Msg-id 87ljmanhbw.fsf@dba2.int.libertyrms.com
Whole thread Raw
In response to Re: SE-PostgreSQL Specifications  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
Responses Re: SE-PostgreSQL Specifications
Re: SE-PostgreSQL Specifications
List pgsql-hackers
sam@samason.me.uk (Sam Mason) writes:
> On Sun, Jul 26, 2009 at 01:42:32PM +0900, KaiGai Kohei wrote:
>> Robert Haas wrote:
>> In some cases, the clearance of infoamtion may be changed. We often
>> have dome more complex requirements also.
>
> OK, so there is some other trusted entity that has unfettered access to
> both databases and its job is to manage these requirements.

No, that's not what this implies.

What this implies is along the following lines...
If a user at the "more secret" level updates some data that had beenclassified at a lower level, then that data gets
reclassifiedat thehigher level.
 

If this sort of outcome is problematic, then that suggests that maybe
the attempt at sharing wasn't such a good idea.

>> Thus, it is necessary a capability to store and manage data objects
>> with different security labeles in a single database instance here.
>> (If we don't want to use commercial solutions instead.)
>
> SE-PG is about doing the above in one database and allowing more
> rigorous checks to be done?

I don't think the issue is so much about "more rigorous"; it's about
having mandatory labelling that is handled consistently.
-- 
(reverse (concatenate 'string "ofni.sesabatadxunil" "@" "enworbbc"))
http://linuxdatabases.info/info/rdbms.html
The people's revolutionary committee has  decided that the name "e" is
retrogressive, unmulticious   and reactionary, and  has  been flushed.
Please update your abbrevs.


pgsql-hackers by date:

Previous
From: Pavel Stehule
Date:
Subject: Re: proposal: support empty string as separator for string_to_array
Next
From: Jeff Davis
Date:
Subject: Re: WIP: Deferrable unique constraints