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: <24603.1490732232@sss.pgh.pa.us>
Date: Tue, 28 Mar 2017 13:36:44 -0700
Cc: Dave Page <dpage@pgadmin.org>,
 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: <CA5B369D-1DA1-4269-8DB5-EEF96DCBE1D5@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>
 <7161672F-1EC5-478F-B307-FF28B01D0D62@gmail.com>
 <19369.1490727172@sss.pgh.pa.us> <248F178D-0A7F-4C6E-963C-BDEFB295!
 CB67@gmail.com> <24603.1490732232@sss.pgh.pa.us>
To: Tom Lane <tgl@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org


> On Mar 28, 2017, at 1:17 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>=20
> Mark Dilger <hornschnorter@gmail.com> writes:
>> I don't see anything wrong with adding roles in pg_authid.h with a #defi=
ne'd
>> Oid.  That's actually pretty helpful for anyone writing code against the=
 database,
>> as they don't have to look up the Oid of the role.
>=20
>> But why not then grant privileges to that role in information_schema.sql=
?=20
>=20
> To the extent that the desired privileges can be represented at the SQL
> level, I agree that that's a better solution than hard-wiring checks in C
> code.  The problem comes in with cases where that's not fine-grained
> enough.  Consider a policy like "anybody can select from pg_stat_activity,
> but unless you have privilege X, the query column should read as nulls
> except for sessions belonging to you".  That behavior can't realistically
> be represented as a separate SQL privilege.  Right now we have "privilege
> X" for this purpose hard-coded as "is superuser", but it would be much
> better if it were associated with a grantable role.

Many thanks for all the explanation.  I now understand better what the
patch is trying to do, and have (with some experimentation) seen flaws
in what I was saying upthread.  I find the notion of a role not being a
group of privileges but instead actually being a privilege confusing, and
it made it hard to think about the security implications of the proposal.
I'm accustomed to the idea of being able to revoke a privilege from a
role, and that doesn't work if the "role" is in some sense a privilege, not
a role.  I might find it all easier to think about if we named these things
privileges and not roles, like pg_read_stats_privilege instead of
pg_read_stats_role, and then we could grant pg_read_stats_privilege
to roles.  But I recall you were saying upthread that you did not want to
have privilege bits for each of these types of things.  I hope this feature
is worth the confusion it causes.

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