Re: Using views for row-level access control is leaky
От | Simon Riggs |
---|---|
Тема | Re: Using views for row-level access control is leaky |
Дата | |
Msg-id | 1256288384.8450.1112.camel@ebony обсуждение исходный текст |
Ответ на | Re: Using views for row-level access control is leaky (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Ответы |
Re: Using views for row-level access control is leaky
Re: Using views for row-level access control is leaky Re: Using views for row-level access control is leaky |
Список | pgsql-hackers |
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. 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
В списке pgsql-hackers по дате отправления: