2009/10/23 Simon Riggs <si...@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 > -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
