Re: Using views for row-level access control is leaky

From: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, 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 10:38:19
Message-ID: 4AE1879B.7060808@kaigai.gr.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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(at)kaigai(dot)gr(dot)jp>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2009-10-23 10:48:51 Re: Using views for row-level access control is leaky
Previous Message Cédric Villemain 2009-10-23 09:23:31 Re: per table random-page-cost?