Re: How to create read-only view on 9.3

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Hannu Krosing <hannu(at)2ndquadrant(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Tomonari Katsumata <katsumata(dot)tomonari(at)po(dot)ntts(dot)co(dot)jp>, Szymon Guz <mabewlun(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: How to create read-only view on 9.3
Date: 2013-08-13 18:53:40
Message-ID: CAHyXU0zVWrnMyWF=1EaDdbFWxStn5vsUar4wRgTBCvAG34HTYg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 13, 2013 at 1:18 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> There's no "security hole" here; if someone can do something that
> they couldn't do before, it's because you explicitly granted them
> privileges to do so.

This point is completely bogus. Very, very few applications I've run
across in the entirety of my career use database enforced security at
all; it's generally done at the application level with the application
role as owner (or perhaps even superuser). You can call people names
or whatever for doing that but the point is it's common usage and
people *will* be affected.

> I don't think you have a lot of room to complain
> if those privileges now do what the SQL standard says they should do.

This point is completely correct and makes the previous argument moot.
This is not a 'security hole' but an 'obfuscation hole' so automatic
correction is not warranted. With the options on the table, I'd
prefer doing nothing or perhaps more strongly worded note in the docs
and possibly the release notes with a slight preference on doing
nothing.

merlin

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2013-08-13 19:20:43 Re: Review: UNNEST (and other functions) WITH ORDINALITY
Previous Message Tom Lane 2013-08-13 18:39:22 Release schedule for PG 9.3