Re: How to get SE-PostgreSQL acceptable
От | KaiGai Kohei |
---|---|
Тема | Re: How to get SE-PostgreSQL acceptable |
Дата | |
Msg-id | 4980FAD6.3080101@ak.jp.nec.com обсуждение исходный текст |
Ответ на | Re: How to get SE-PostgreSQL acceptable (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: How to get SE-PostgreSQL acceptable
|
Список | pgsql-hackers |
Andrew Dunstan wrote: > Tom Lane wrote: >> As an example, the present patch imagines that it will have adequate >> control over inserts by putting hooks into simple_heap_insert and the >> (rather small number of) places that call heap_insert directly. But >> there are dozens of calls of simple_heap_insert and no way for the >> function itself to know why it is being called or on whose behalf. >> The patch's hook function tries to work around the fact that it hasn't >> got that information by means of heuristics. Aside from the question of >> whether there are bugs in those heuristics today (I'm certain there >> are), every time we accept a patch that adds another call of >> simple_heap_insert, we're going to have to revisit the hook to see >> if it needs to be twiddled. >> >> Another problem is that since the hook only knows the parameters to >> simple_heap_insert plus global state (such as current_user), it can't >> cope very well with security-related context changes. We have already >> heard that situations involving views are simply broken in the patch as >> it stands --- row-level permissions are checked against current_user >> and not the view owner, and there's no good way to fix that. >> > > Leaving aside any other issues, it seems to me that the chance of > remedying these defects reasonably in a couple of weeks is just about nil. > > That leaves the following questions: can the row-level part of the patch > be separated out, and if so how easily, and is what would be left worth > doing? At least, I believe the row-level access control make PostgreSQL more attractive in security aspect like a few major commercial dbms, and its tradeoff (PK/FK covert channel, optimization issue) should be a decision by end-users. However, I can accept an opinion the row-level facilities can be separated and postponed, then, step-by-step enlargement approach, as Peter & Stephen suggested. Even if we don't have row-level at v8.4, column-level MAC has its (may be limited) worth, for example, a column to store credit-card number never visible from web application context. I found a proverbial phrase in my dictionaly: Between two stools you fall to the ground. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления: