On Fri, Mar 24, 2017 at 4:24 PM, Robert Haas <robertmh...@gmail.com> wrote: > >> If we make the users run all the statements individually then they'll >> also have to get an updated script for the next version of PG too >> because we will have added things that the tools will want access to. > > That's possible, but it really depends on the tool, not on core > PostgreSQL. The tool should be the one providing the script, because > the tool is what knows its own permissions requirements. Users who > care about security won't want to grant every privilege given by a > pg_monitor role to a tool that only needs a subset of those > privileges.
The upshot of this would be that every time there's a database server upgrade that changes the permissions required somehow, the user has to login to every server they have and run a script. It is no longer a one-time thing, which makes it vastly more painful to deal with upgrades. >> With the approach that Dave and I are advocating, we can avoid all of >> that. Contrib modules can bake-in GRANTs to the appropriate roles, >> upgrades can be handled smoothly even when we add new capabilities which >> are appropriate, users have a simple and straight-forward way to set up >> good monitoring, and tool authors will know what permissions are >> available and can finally have a better answer than "well, just make the >> monior user superuser if you want to avoid all these complexities." > > They can have that anyway. They just have to run a script provided by > the tool rather than one provided by the core project as a > one-size-fits-all solution for every tool. Do you object to having individual default roles specifically for cases where there are superuser-only checks at the moment that prevent GRANT? e.g. pg_show_all_settings for SHOW, pg_show_all_stats for pg_tablespace_size and friends, pg_stat_statements for, well, pg_stat_statements and so on? It would be an inferior solution in my opinion, given that it would demonstrably cause users more work, but at least we could do something. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: @pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
