Simon Riggs wrote:
> On Fri, 2009-10-23 at 11:30 +0300, Heikki Linnakangas wrote:
>
>> The most user-friendly and backwards-compatible (though not necessarily
>> back-patchable) approach I can see is:
>>
>> 1. If the user has read access to all the underlying tables, plan it
>> like we do today.
>
> For me, it would make most sense to explicitly mark Views as being
> security views. That way planning need only change when we are
> optimizing a query that accesses a view with plan security enabled.
>
> ALTER VIEW foo ENABLE PLAN SECURITY;
>
> That is much clearer and easily to verify/audit, so more secure.
The point is that only owner knows intention of the view correctly.
It seems to me reasonable to explicitly mark whether the major purpose
of view is security, or not.
> Also, we should presume that any function created with SECURITY DEFINER
> and created by a superuser would have plan security, so we don't need to
> annotate lots of old code to work securely. Annotating the built-in
> functions is a lot easier.
Sorry, what is happen if function is marked as "plan security"?
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>