From: Tom Lane <tgl@sss.pgh.pa.us>
To: Jordan Gigov <coladict@gmail.com>
cc: Robert Haas <robertmhaas@gmail.com>, Stephen Frost <sfrost@snowman.net>,
        Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
        Michael Banck <michael.banck@credativ.de>,
        Jim Nasby <Jim.Nasby@bluetreble.com>,
        Kevin Grittner <kgrittn@gmail.com>,
        Pg Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Change in "policy" on dump ordering?
In-reply-to: 
 <CA+nBocCTj5NAsrhEYOvY4YDo-Yg6YU5eAmhFq3NK+-K97MmxUA@mail.gmail.com>
References: <8f64786e-824d-7c0d-33a6-3d9e1c8e9fde@2ndquadrant.com>
 <edc1dc0d-66ba-0d9e-b0e7-890f064789d7@BlueTreble.com>
 <33b25c65-94f1-6ff6-c717-61a56294a255@2ndquadrant.com>
 <a537995b-ccdb-f668-5f67-98e9b9b4a99d@BlueTreble.com>
 <75409fb1-bd96-25c2-f6b0-c24e28ed2684@2ndquadrant.com>
 <65049c27-96bf-317b-b435-931f6041f94c@BlueTreble.com>
 <67d35333-ef65-074a-b2be-52440f245e43@2ndquadrant.com>
 <753dcafc-a648-9041-e9ca-e405cd4498f4@2ndquadrant.com>
 <20170306083342.GA8374@nighthawk.caipicrew.dd-dns.de>
 <2605f6d0-8444-528e-4e38-6b13968cfeb7@2ndquadrant.com>
 <20170306140101.GQ9812@tamriel.snowman.net> <28572.1500912583@sss.pgh.pa.us>
 <18658.1501037135@sss.pgh.pa.us>
 <CA+TgmoYiUTPQGCjHYJ6DeiR1Qf-74XFO2Rp2WZnA88FdorZg6g@mail.gmail.com>
 <22969.1501075830@sss.pgh.pa.us>
 <CA+nBocCTj5NAsrhEYOvY4YDo-Yg6YU5eAmhFq3NK+-K97MmxUA@mail.gmail.com>
Comments: In-reply-to Jordan Gigov <coladict@gmail.com>
	message dated "Wed, 26 Jul 2017 17:11:11 +0300"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <8698.1501083355.1@sss.pgh.pa.us>
Date: Wed, 26 Jul 2017 11:35:55 -0400
Message-ID: <8699.1501083355@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

Jordan Gigov <coladict@gmail.com> writes:
> But why should a superuser need the ACL to be applied before being allowed
> access? If you make the permission-checking function check if the user is a
> superuser before looking for per-user grants, wouldn't that solve the issue?

The superuser's permissions are not relevant, because the materialized
view is run with the permissions of its owner, not the superuser.
We are not going to consider changing that, either, because it would open
trivial-to-exploit security holes (any user could set up a trojan horse
matview and just wait for the next pg_upgrade or dump/restore).

			regards, tom lane


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers