On Sat, Mar 25, 2017 at 12:30 PM, Dave Page <dpage@pgadmin.org> wrote:
> Right - and if a user doesn't like it, they can easily just not use the default role and create their own alternative
instead.
OK, I see the points that both of you are making and I admit that
they've got some validity to them. Let me make a modest proposal.
Suppose we define the pg_monitor role as strictly a bundle of
privileges that could be granted individually if desired, and
similarly define pg_read_all_settings and pg_read_all_stats as roles
that are strictly recognized by the code, without any grants. So
instead of this:
GRANT EXECUTE ON FUNCTION pgstatindex(regclass) TO pg_read_all_stats;
We'd instead do this:
GRANT EXECUTE ON FUNCTION pgstatindex(regclass) TO pg_monitor;
(and similarly for all other GRANT statements that appear in the patch)
So, if you want, you can give somebody pg_read_all_stats, enhancing
their access to functions to which they already have access, but deny
them execute access on some of the individual functions. The
permissions with which pg_monitor ends up are unchanged, but somebody
creating their own role has a bit more freedom to customize what it
can do.
I still don't have much confidence in the theory that every monitoring
solution ever will want the same privileges, but if we unbundle things
as much as we reasonably can, then the worst thing that happens if
pg_monitor turns out to be not what everyone wants is that some people
do it a different way instead. Which as you say is not that bad.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
