(2010/06/02 10:52), Robert Haas wrote:
> 2010/6/1 KaiGai Kohei<kaigai@ak.jp.nec.com>:
>>> Eh, if that's the consensus, it doesn't bother me that much, but it
>>> doesn't really answer the question, either: supposing we add an
>>> explicit concept of a security view, what should its semantics be?
>>
>> How about a GUC option to provide the default, like default_with_oids?
>
> Bad idea. We already have enough problems with GUCs that can create
> security problems if they're unexpectedly set to the wrong value. We
> don't need any more. Anyhow, that's trivia. The real thing we need
> to decide here is to design the security mechanism. We can change the
> syntax to whatever we want very easily.
>
Indeed, syntax will be decided according to the logic.
> Here's another thought. If we're leaning toward explicit syntax to
> designate security views (and I do mean IF, since only one person has
> signed on to that, even if it is Tom Lane!), then maybe we should
> think about ripping out the logic that causes regular views to be
> evaluated using the credentials of the view owner rather than the
> person selecting from it. A security view would still use that logic,
> plus whatever additional stuff we come up with to prevent leakage.
> Perhaps this would be viewed as a nasty backward compatibility break,
> but the upside is that we'd then be being absolutely clear that a
> non-security view isn't and can never be trusted to be a security
> barrier. Right now we're shipping something that purports to act as a
> barrier but really doesn't.
>
Sorry, should we make clear the purpose of explicit syntax for security
views being issued now?
In my understanding, if security views, the planner tries to checks
privileges of the person selecting it to reference underlaying tables
without any ereport. If violated, the planner prevents user given
quals (perhaps FuncExpr only?) to come into inside of the join scan.
Otherwise, if regular views, the planner works as is. Right?
I don't think we need whatever additional user visible stuff to prevent
leakage except for fully optimized query plan. (Of course, it can make
performance regression.)
It seems to me the issue is just an order to execute user defined
functions and qualifier of security views to restrict visible tuples,
so I don't know whether it breaks any backward compatibility.
Thanks,
--
KaiGai Kohei <kaigai@ak.jp.nec.com>
