From: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
---|---|
To: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: How to get SE-PostgreSQL acceptable |
Date: | 2009-01-29 00:39:50 |
Message-ID: | 4980FAD6.3080101@ak.jp.nec.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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(at)ak(dot)jp(dot)nec(dot)com>
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2009-01-29 01:12:40 | Re: 8.4 release planning |
Previous Message | Joshua Brindle | 2009-01-29 00:31:18 | Re: How to get SE-PostgreSQL acceptable |