Re: How to create read-only view on 9.3 - Mailing list pgsql-hackers

From Merlin Moncure
Subject Re: How to create read-only view on 9.3
Date
Msg-id CAHyXU0zVWrnMyWF=1EaDdbFWxStn5vsUar4wRgTBCvAG34HTYg@mail.gmail.com
Whole thread Raw
In response to Re: How to create read-only view on 9.3  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Aug 13, 2013 at 1:18 PM, Tom Lane <tgl@sss.pgh.pa.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



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Release schedule for PG 9.3
Next
From: Robert Haas
Date:
Subject: Re: Review: UNNEST (and other functions) WITH ORDINALITY