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 <kai...@kaigai.gr.jp>
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
