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+OCxox8HW6obNKY5atVA6pX=Z=wQw6rTGcggy4N05k=mLkaAQ@mail.gmail.com>
Date: Tue, 28 Mar 2017 09:04:15 -0700
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>,
 Stephen Frost <sfrost@snowman.net>,
 Robert Haas <robertmhaas@gmail.com>,
 PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <FEE8D3A7-FDBF-432F-BEEF-F28B7D3AD2F4@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>
To: Dave Page <dpage@pgadmin.org>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


> On Mar 28, 2017, at 8:34 AM, Dave Page <dpage@pgadmin.org> wrote:
>=20
> On Tue, Mar 28, 2017 at 11:31 AM, Peter Eisentraut
> <peter.eisentraut@2ndquadrant.com> wrote:
>> This patch touches the pg_buffercache and pg_freespacemap extensions,
>> but there appear to be some files missing.
>=20
> Are you looking at an old version? There was one where I forgot to add
> some files, but that was fixed within an hour or so in a new version.
>=20
> Right now I'm waiting for discussion to conclude before updating the
> patch again.

There does not seem to be a new patch since Robert made his "modest proposa=
l",
so I guess I just have to ask questions about how this would work.

I don't see any precedent in the code for having a hardcoded role, other th=
an
superuser, and allowing privileges based on a hardcoded test for membership
in that role.  I'm struggling to think of all the security implications of =
that.

If I have even one table in my database which is security sensitive, such t=
hat
I cannot allow users to see the size of the table, nor whether the table has
unvacuumed rows (owing to the fact that would give away that it has been
changed since the last vacuum time), then I can't use pg_real_all_stats for
anything, right?  And I would need to exercise some due diligence to make
certain it does not get granted to anybody?

What happens if I execute:

REVOKE ALL ON TABLE mysecuretable FROM pg_read_all_stats?

Does it work?  Does it silently fail?  Does it raise an exception?  Does
pg_read_all_stats still have access to stats for mysecuretable?

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