On Mon, May 3, 2021 at 2:48 PM Tom Lane <t...@sss.pgh.pa.us> wrote: > I'm still of the opinion that slicing and dicing this at the per-GUC > level is a huge waste of effort. Just invent one role that lets > grantees set any GUC, document it as being superuser-equivalent, > and be done.
If you want to grant someone full superuser rights, you can do that already. The trick is what to do when you want someone to be able to administer the cluster in a meaningful way without giving them full superuser rights. I agree that in some cases it's fine to have predefined roles that are known to permit easy escalation to superuser privileges, like pg_execute_server_program. It doesn't provide any real security, but like you said, it can help prevent mistakes. However, there is a real use cases for a privileged user who cannot be permitted to escalate to superuser or to the OS account, but still needs to be able to do some administration of the cluster. The scenario Mark laid out in his original post is very common. In fact, it may already be the dominant model for PostgreSQL deployment, and if it isn't now, it will be in 5 years. Letting each individual company that's providing a hosted PostgreSQL solution hack up its own solution to that problem, all of which are subtly incompatible with each other and with upstream, is not good for users or the project. -- Robert Haas EDB: http://www.enterprisedb.com
