Re: Monitoring roles patch - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Monitoring roles patch
Date
Msg-id 20170328184348.GI9812@tamriel.snowman.net
Whole thread Raw
In response to Re: Monitoring roles patch  (Mark Dilger <hornschnorter@gmail.com>)
List pgsql-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

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Protection lost in expression eval changeover
Next
From: Nikolay Shaplov
Date:
Subject: Re: [PATCH] Move all am-related reloption code into src/backend/access/[am-name] and get rid of relopt_kind for custom AM