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: <957FCA21-99DA-4477-9A6E-C86ACAC23E36@gmail.com>
Date: Tue, 28 Mar 2017 11:34:03 -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: <7161672F-1EC5-478F-B307-FF28B01D0D62@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>
 <957FCA21-99DA-4477-9A6E-C86ACAC23E36@gmail.com>
To: Dave Page <dpage@pgadmin.org>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


> On Mar 28, 2017, at 11:06 AM, Mark Dilger <hornschnorter@gmail.com> wrote:
>=20
>=20
>> On Mar 28, 2017, at 9:47 AM, Dave Page <dpage@pgadmin.org> wrote:
>>=20
>>> Does
>>> pg_read_all_stats still have access to stats for mysecuretable?
>>=20
>> Yes, because the ACL on the table controls reading/writing the data in
>> the table. It doesn't have any bearing on any kind of table metadata.
>> A user who has no privileges on a table can already look at (for
>> example) pg_stat_all_tables and see the sort of info you're talking
>> about. This patch would just allow members of a specific role get the
>> on-disk size as well, *if* you choose to use it.
>=20
> I don't entirely agree here.  Security conscious database users may well
> restrict access to that view.  I added a check to the regression tests to
> verify that it works:
>=20
> + SET ROLE regress_locktable_user;
> + SELECT COUNT(*) FROM pg_stat_all_tables;
> +  count=20
> + -------
> +    290
> + (1 row)
> +=20
> + RESET ROLE;
> + REVOKE ALL PRIVILEGES ON pg_stat_all_tables FROM PUBLIC;
> + SET ROLE regress_locktable_user;
> + SELECT COUNT(*) FROM pg_stat_all_tables;
> + ERROR:  permission denied for relation pg_stat_all_tables
> + RESET ROLE;
> + SELECT COUNT(*) FROM pg_stat_all_tables;
> +  count=20
> + -------
> +    292
> + (1 row)
> +=20
>=20
> The inability to revoke access to this sort of information being proposed
> makes me a bit uneasy.  Mostly, I think, I'm bothered because there may
> be people who have revoked privileges on a lot of things, thereby restric=
ting
> access to superuser, who won't necessarily notice this new feature in
> postgres 10.  That could be a source of security holes that we get blamed
> for.

After a bit of introspection, I think what is really bothering me is not the
inability to revoke permissions, since as you say I can choose to not assign
the role to anybody.  What bothers me is that this feature implicitly redef=
ines
what is meant by the keyword PUBLIC.  If I go around the database
revoking privileges on everything from PUBLIC, I should end up with
a database that is inaccessible to anyone but superuser, right?  All views,
functions, tables, etc., would all be locked down.  But after this proposed
change, IIUC, there would still be a bit of access available to this/these
proposed non-superuser role(s) which have hardcoded permissions.

That's quite a significant change to the security model of the database,
and I don't think it is something users would expect from the release notes
if the release notes for this feature say something like:

	"added database monitoring functionality"

To be fair, I have not tried to revoke everything from everybody on a
database to verify that their aren't already problems of this sort.  Perhaps
the cows have already left the barn.

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