Re: [PATCH] Fix leaky VIEWs for RLS

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, marc(at)bloodnok(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH] Fix leaky VIEWs for RLS
Date: 2010-06-04 18:00:19
Message-ID: AANLkTimfhs6q5DCBP1IogCQdHX7mwoHrzLmT_u9So4JF@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Jun 4, 2010 at 1:46 PM, Heikki Linnakangas
<heikki(dot)linnakangas(at)enterprisedb(dot)com> wrote:
> On 04/06/10 17:33, Tom Lane wrote:
>>
>> Heikki Linnakangas<heikki(dot)linnakangas(at)enterprisedb(dot)com>  writes:
>>>
>>> On 04/06/10 07:57, Tom Lane wrote:
>>>>
>>>> The proposal some time back in this thread was to trust all built-in
>>>> functions and no others.
>>
>>> I thought I debunked that idea already
>>> (http://archives.postgresql.org/pgsql-hackers/2009-10/msg01428.php) Not
>>> all built-in functions are safe. Consider casting integer to text, for
>>> example.
>
> (I meant "text to integer", of course)
>
>> Maybe the entire idea is unworkable.  I certainly don't find any comfort
>> in your proposal in the above-referenced message to trust index
>> operators; where is it written that those don't throw errors?
>
> Let's consider b-tree operators for an index on the secure table, for
> starters. Surely a b-tree index comparison operator can't throw an error on
> any value that's in the table already, you would've gotten an error trying
> to insert that.
>
> Now, is it safe to expand that thinking to b-tree operators in general, even
> if there's no such index on the table? I'm not sure. But indexable
> operations are what we care about the most; the order of executing those
> determines if you can use an index scan or not.

Another idea I had was... would it be safe to trust functions defined
by the same user who owns the view? If he's granted access to the
view and the function to some other user, presumably he doesn't mind
them being used together? Or is that too optimistic?

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Page 2010-06-04 18:28:04 Re: Did we really want to force an initdb in beta2?
Previous Message Bruce Momjian 2010-06-04 17:57:58 Re: Idea for getting rid of VACUUM FREEZE on cold pages