2009/10/23 Simon Riggs <simon@2ndquadrant.com>:
> 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;
+1
Pavel
>
> That is much clearer and easily to verify/audit, so more secure.
>
> 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.
>
>> 2. If the view refers only one table (as a typical Veil view does), plan
>> it like we do today but enforce that view conditions are evaluated first
>> in the Filter. Notably, allow using any user-supplied conditions as
>> index quals if there's a matching index.
>>
>> 3. Otherwise fully materialize the view.
>
> So if we join a normal table or a view to a secure view then only the
> secure view part would be materialized? Or do you mean the whole query
> would be materialized?
>
> --
> Simon Riggs www.2ndQuadrant.com
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>