Re: SE-PostgreSQL Specifications
От | KaiGai Kohei |
---|---|
Тема | Re: SE-PostgreSQL Specifications |
Дата | |
Msg-id | 4A6BDEB8.1080906@kaigai.gr.jp обсуждение исходный текст |
Ответ на | Re: SE-PostgreSQL Specifications (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: SE-PostgreSQL Specifications
|
Список | 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 по дате отправления: