Re: leaky views, yet again

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>

To: Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, KaiGai Kohei <kaigai@ak.jp.nec.com>, Itagaki Takahiro <itagaki.takahiro@gmail.com>, KaiGai Kohei <kaigai@kaigai.gr.jp>, pgsql-hackers@postgresql.org

Date: 2010-10-07T12:24:42Z

Lists: pgsql-hackers

Attachments

document-leaky-views-v2.patch (application/octet-stream) patch v2

On Thu, Oct 7, 2010 at 2:02 AM, Heikki Linnakangas
<heikki.linnakangas@enterprisedb.com> wrote:
> On 07.10.2010 06:39, Robert Haas wrote:
>>
>> On Tue, Oct 5, 2010 at 3:42 PM, Tom Lane<tgl@sss.pgh.pa.us>  wrote:
>>>
>>> Right, *column* filtering seems easy and entirely secure.  The angst
>>> here is about row filtering.  Can we have a view in which users can see
>>> the values of a column for some rows, with perfect security that they
>>> can't identify values for the hidden rows?  The stronger form is that
>>> they shouldn't even be able to tell that hidden rows exist, which is
>>> something your view doesn't try to do; but there are at least some
>>> applications where that would be desirable.
>>
>> I took a crack at documenting the current behavior; see attached.
>
> Looks good. It gives the impression that you need to be able to a create
> custom function to exploit, though. It would be good to mention that
> internal functions can be used too, revoking access to CREATE FUNCTION does
> not make you safe.

OK, second try attached.

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