Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Subject: Re: Monitoring roles patch
From: Mark Dilger <hornschnorter@gmail.com>
In-Reply-To: 
 <CA+TgmoZA-gM+Un0E65seyVT45axpaH8q-QRDs8L+nSUrynkSMA@mail.gmail.com>
Date: Tue, 28 Mar 2017 10:52:40 -0700
Cc: Dave Page <dpage@pgadmin.org>,
 Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
 Stephen Frost <sfrost@snowman.net>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <B63B4B66-6063-4743-BB45-5AF2C2B47D87@gmail.com>
References: 
 <CA+OCxoyRdsc1xyLfF9s698gUGyPXBs4CvJ+0Gwo8U65NmYJ7pw@mail.gmail.com>
 <CA+TgmobveXzVPytFOO3AkmsM+Y=YEG+UXcCvgwAt+SgYj85OCA@mail.gmail.com>
 <CA+OCxox9c9-1=bXxA6-gr-iWZbD5zdHYMz=cpC034RKB7zX40Q@mail.gmail.com>
 <CA+TgmoZ5zs50mEzALJqp3qBMC+CdT0ccnjvNJt1Ojiu9rz35zw@mail.gmail.com>
 <20170322131510.GC9812@tamriel.snowman.net>
 <CA+OCxoyt9OMWaK=g2sL8qCTcwrS-8j3=06AZLzXQZ61sUn7gtA@mail.gmail.com>
 <CA+OCxozGTGd-x+cx03N=KJVK=soJwOpTWkq_=zac3P04aBCU4Q@mail.gmail.com>
 <20170323122335.GK9812@tamriel.snowman.net>
 <CA+OCxozZxJouNjY4+-heYSUk=qagoytQXnSjMyO5-R_a_mddKA@mail.gmail.com>
 <c1d3db24-85f0-96bb-0ec3-aeddd9d35941@2ndquadrant.com>
 <CA+OCxox8HW6obNKY5atVA6pX=Z=wQw6rTGcggy4N05k=mLkaAQ@mail.gmail.com>
 <FEE8D3A7-FDBF-432F-BEEF-F28B7D3AD2F4@gmail.com>
 <CA+OCxoy7rqEZ65byS+3E_0dsTKYD8NcUzQB1SiGknARmbxBTDg@mail.gmail.com>
 <CA+TgmoZA-gM+Un0E65seyVT45axpaH8q-QRDs8L+nSUrynkSMA@mail.gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


> On Mar 28, 2017, at 9:55 AM, Robert Haas <robertmhaas@gmail.com> wrote:
>=20
> On Tue, Mar 28, 2017 at 12:47 PM, Dave Page <dpage@pgadmin.org> wrote:
>>> I don't see any precedent in the code for having a hardcoded role, othe=
r than
>>> superuser, and allowing privileges based on a hardcoded test for member=
ship
>>> in that role.  I'm struggling to think of all the security implications=
 of that.
>>=20
>> This would be the first.
>=20
> Isn't pg_signal_backend an existing precedent?

Sorry, I meant to say that there is no precedent for allowing access to dat=
a based
on a hardcoded test for membership in a role other than superuser.  All the
locations that use pg_signal_backend are checking for something other than
data access privileges.  That distinction was clear to me in the context of=
 what I
was saying, but I obviously didn't phrase it right in my email.

mark

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