Re: [RFC] A tackle to the leaky VIEWs for RLS

On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> CREATE SECURITY VIEW, anyone?
>
>> That may be the best approach, but I think it needs more than one line
>> of exposition.  The approach I proposed was to test whether the user
>> has privileges to execute the underlying query directly without going
>> through the view.  If so, we needn't be concerned.  If not, then we
>> start thinking about which functions/operators we trust.
>
> Ummm ... that makes semantics dependent on the permissions available at
> plan time, whereas what should matter is the permissions that exist at
> execution time.  Maybe that's all right for this context but it doesn't
> seem tremendously desirable.

Ugh. I hope there's a way around that problem because AFAICS the
alternative is a world of hurt. If we're not allowed to take the
security context into account during planning, then we're going to
have to make worst-case assumptions, which sounds really unpleasant.

>> Perhaps there is some value to having a knob that goes the opposite
>> directions and essentially says "I don't really care whether this view
>> is leaky from a security perspective".  But presumably we don't want
>> to deliver that behavior by default and require the user to ask for a
>> SECURITY VIEW to get something else - if anything, we'd want CREATE
>> VIEW to create the normal (secure) version and add CREATE LEAKY VIEW
>> to do the other thing.
>
> -1 on that.  We will get far more pushback from people whose application
> performance suddenly went to hell than we will ever get approval from
> people who actually need the feature.  Considering that we've survived
> this long with leaky views, that should definitely remain the default
> behavior.

Eh, if that's the consensus, it doesn't bother me that much, but it
doesn't really answer the question, either: supposing we add an
explicit concept of a security view, what should its semantics be?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company