From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
Cc: | Marc Munro <marc(at)bloodnok(dot)com>, Rod Taylor <rod(dot)taylor(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Using views for row-level access control is leaky |
Date: | 2009-10-23 08:59:44 |
Message-ID: | 1256288384.8450.1112.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Pavel Stehule | 2009-10-23 09:13:22 | Re: Using views for row-level access control is leaky |
Previous Message | Heikki Linnakangas | 2009-10-23 08:30:23 | Re: Using views for row-level access control is leaky |