Re: leaky views, yet again

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, Itagaki Takahiro <itagaki(dot)takahiro(at)gmail(dot)com>, Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: leaky views, yet again
Date: 2010-10-05 16:27:12
Message-ID: 25880.1286296032@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Oct 5, 2010 at 10:56 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Personally I think this is a dead end that we shouldn't be wasting
>> any more time on.

> But you haven't proposed a reasonable alternative.

Tom: "This problem is insoluble."
Robert: "You can't claim that without offering a solution."

Sorry ...

> Option #1: Remove all mention from the documentation of using views
> for security purposes. Don't allow views to have explicit permissions
> attached to them; they are merely shorthand for a SELECT, for which
> you either do or do not have privileges.

The SQL standard requires us to attach permissions to views. The
standard makes no claims whatsoever about how leak-proof views should
be; it only says that you can't call a view without the appropriate
permissions.

I do think it's reasonable for the docs to point out that views that do
row-filtering should not be presumed to be absolutely bulletproof.
That doesn't make permissions on them useless, so you're attacking a
straw man.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Joshua D. Drake 2010-10-05 16:31:56 Re: leaky views, yet again
Previous Message Tom Lane 2010-10-05 16:16:15 Re: configure gaps