Re: How to get SE-PostgreSQL acceptable
От | Andrew Dunstan |
---|---|
Тема | Re: How to get SE-PostgreSQL acceptable |
Дата | |
Msg-id | 4980EE44.50202@dunslane.net обсуждение исходный текст |
Ответ на | Re: How to get SE-PostgreSQL acceptable (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: How to get SE-PostgreSQL acceptable
|
Список | pgsql-hackers |
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? cheers andrew
В списке pgsql-hackers по дате отправления: