On Tue, Jun 1, 2010 at 1:28 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Jun 1, 2010 at 1:02 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> On Tue, Jun 1, 2010 at 10:57 AM, Tom Lane <tgl@sss.pgh.pa.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'? :-)
merlin