From: Stephen Frost <sfrost@snowman.net>
To: Mark Dilger <hornschnorter@gmail.com>
Cc: Dave Page <dpage@pgadmin.org>
Cc: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Subject: Re: Monitoring roles patch
Date: Tue, 28 Mar 2017 14:43:48 -0400
Message-ID: <20170328184348.GI9812@tamriel.snowman.net> (raw)
In-Reply-To: <7161672F-1EC5-478F-B307-FF28B01D0D62@gmail.com>
References: <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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
Greetings,
* Mark Dilger (hornschnorter@gmail.com) wrote:
> 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 redefines
> 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?
While I accept your concern and confusion, this isn't accurate.
REVOKE'ing rights from PUBLIC only removes those rights GRANT'd to
PUBLIC, it doesn't remove rights which have been GRANT'd to other users.
In a degenerate system where the only roles which exist are the
superuser role and the pseudo-role 'public', you would be correct with
your statement above, but this patch doesn't change that because you
will not have GRANT'd the new role to anyone.
> 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.
These non-superuser roles can't be logged into and if they are not
GRANT'd to anyone then it's essentially the same as if they don't exist.
> 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"
Having more in the release notes and in the documentation is certainly
important, but this is not changing the security model of the database
in any significant way.
> 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.
Right, which means that, in addition to the points made above, this
isn't a use-case which is actually even all that interesting to
consider.
Thanks!
Stephen
Attachments:
signature.asc (application/pgp-signature, 818B) download
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: sfrost@snowman.net, hornschnorter@gmail.com, dpage@pgadmin.org, peter.eisentraut@2ndquadrant.com, robertmhaas@gmail.com
Subject: Re: Monitoring roles patch
In-Reply-To: <20170328184348.GI9812@tamriel.snowman.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox