Re: How to get SE-PostgreSQL acceptable
От | Gregory Stark |
---|---|
Тема | Re: How to get SE-PostgreSQL acceptable |
Дата | |
Msg-id | 87hc3jjlte.fsf@oxford.xeocode.com обсуждение исходный текст |
Ответ на | Re: How to get SE-PostgreSQL acceptable (Joshua Brindle <method@manicmethod.com>) |
Ответы |
Re: How to get SE-PostgreSQL acceptable
|
Список | pgsql-hackers |
Joshua Brindle <method@manicmethod.com> writes: > partitions don't help because, once again, the application would be making the > determination about which partition to query. Not necessarily since the database can be programmed to automatically put the records into the right partition. Right now it's a pain but we're definitely headed in that direction. > Further, partitioning isn't fine grained. I can't say user X can read secret > rows and read/write top secret rows and get that data out in a transparent way > (the applications would have to be aware of the partitions). Relabeling of data > also looks like a challenge with partitions (if I correctly understand how they > work). I think the "transparent" is the source of the problem. The application should issue a query for the data it wants. It shouldn't "transparently" get magic extra clauses attached to the query. That's where the SQL semantics are being violated. Row-level security isn't inherently a problem. It's just that the security is affecting the data returned that's causing a problem. I don't think partitioning is really the same thing as row-level security. But I wonder if some of the same infrastructure could be used for both -- once we have it. -- Gregory Stark EnterpriseDB http://www.enterprisedb.com Get trained by Bruce Momjian - ask me about EnterpriseDB'sPostgreSQL training!
В списке pgsql-hackers по дате отправления: