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

From KaiGai Kohei
Subject Re: SE-PostgreSQL Specifications
Date
Msg-id 4A6BDEB8.1080906@kaigai.gr.jp
Whole thread Raw
In response to Re: SE-PostgreSQL Specifications  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: SE-PostgreSQL Specifications
List pgsql-hackers
Robert Haas wrote:
>>> If superusers DON'T exist, that would be making the opposite
>>> statement, namely, that there isn't ANY WAY to get a backup that you
>>> can be sure DOES contain all of the objects.
>> The traditional approach would be to maintain multiple physically
>> separate databases; in this setup it's obvious that when you perform a
>> backup of one of these databases you're only seeing a subset of "all of
>> the objects".  Isn't SE-PG just allowing you to do this within a single
>> PG database?
> 
> Partly.  There's also a concept called "read down", which is
> important.  It allows you to have, say, secret and classified data in
> the same database, and let the secret users see both types but the
> classified users see only the classified stuff, not the secret stuff.
> 
> If you want to store intelligence data about the war in Iraq and
> intelligence data about the war in Afghanistan, it might not be too
> bad to store them in separate databases, though storing them in the
> same database might also make things simpler for users who have access
> to both sets of data.  But if you have higher and lower
> classifications of data it's pretty handy (AIUI) to be able to let the
> higher-secrecy users read the lower-secrecy data - if you used
> separate databases to simulate read-down, you'd have to replicate data
> between them, and also have some manual mechanism for tracking which
> level of secrecy applied to which to which data.

It seems a correct description.

In addition, we also need to prevent that higher-secrecy users writes
anything to the lower-secrect objects to prevent information leaks.
In some cases, the clearance of infoamtion may be changed. We often
have dome more complex requirements also.

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

Thanks,
-- 
KaiGai Kohei <kaigai@kaigai.gr.jp>


pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: SE-PostgreSQL Specifications
Next
From: Petr Jelinek
Date:
Subject: Re: [PATCH] DefaultACLs