From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Greg Stark <gsstark(at)mit(dot)edu>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, pgsql-hackers(at)postgresql(dot)org, sfrost(at)snowman(dot)net |
Subject: | Re: [RFC] A tackle to the leaky VIEWs for RLS |
Date: | 2010-06-01 20:57:34 |
Message-ID: | AANLkTiljmQOOrYYrML66utcdptOUSCe-vpdkZSL_QfDj@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jun 1, 2010 at 4:10 PM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Tue, Jun 1, 2010 at 1:28 PM, Robert Haas <robertmhaas(at)gmail(dot)com> 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.
>>
>>>> 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?
>
> have you ruled out: 'create function'? :-)
You lost me...
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2010-06-01 21:22:39 | Re: [RFC] A tackle to the leaky VIEWs for RLS |
Previous Message | Peter Eisentraut | 2010-06-01 20:50:57 | Re: How to pass around collation information |