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

(2010/06/02 2:28), Robert Haas wrote:
> 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.
>
I was reminded that inline_set_returning_function() tries to extract
a given RangeTblEntry with RTE_FUNCTION into a subquery when a few
conditions are satisfied. The conditions include whether user has
privileges to execute the function.

It seems to me planner checks permissions, and going to have worst
case assumptions, if access privilege violations.

As long as we can resolve the problem that I described at [1] (order
of evaluation of scan filters), it seems to me a reasonable fallback.
(Although I mentioned that queries are optimized prior to execution stage...)

>>> 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?
>

How about a GUC option to provide the default, like default_with_oids?

Thanks,
--
KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>