> adrian.klaver@xxxxxxxxxxx wrote: > >> Karsten.Hilbert@xxxxxxx: >> >>> adrian.klaver@xxxxxxxxxxx wrote: >>> >>>> bryn@xxxxxxxxxxxx >>>> >>>> Thanks to all who offered their views on my question. It seems that different people will reach different conclusions. I’ll take this as permission to reach my own conclusion. >>> >>> Not sure why you think you need permission to take whatever action you desire on a database whose only usage stipulation is that you maintain a copy of the license. >> >> Adrian, I think Bryn's speaking metaphorically there. > > It is hard to tell with him. He makes much of his Oracle background and I think misses an overlord that lays down the rules. I didn’t mean to speak metaphorically. But I made a bad word choice when I used “permission”. A couple of turns back, David Johnston wrote this: > there is no good blanket recommendation to give to someone else as to how their [security] policy should be written. Security, especially of this sort, needs to be architected. And some time ago, in a different thread, he wrote this: > You only need superuser once to configure the system in such a way, through role and grants and possibly default permissions, that from then on most everything an application user would want to do can be done by the role(s) you have created. That second quote reads like a recommendation—which puts it at odds with the first quote. (But doubtless I’m reading it wrongly.) Then there’s this (from the doc): > It is good practice to create a role that has the CREATEDB and CREATEROLE privileges, but is not a superuser, and then use this role for all routine management of databases and roles. This approach avoids the dangers of operating as a superuser for tasks that do not really require it. That, too, reads like a recommendation that intends to inform a security policy. But, I suppose, one could argue that saying something “is good practice” is very different from making a recommendation. Consider this wording. It also uses “good practice”. « It is good practice to limit the number of superuser roles that exist in a cluster to exactly one: the inevitable bootstrap superuser. This recognizes the fact that, once the initial configuration of a cluster has been done immediately after its creation (which configuration is done while still in self-imposed single-user mode), there are then very few, and infrequent, tasks that require the power of the superuser role. » Nobody supports it! I’m puzzled why the good practice statement about a role with the CREATEDB and CREATEROLE attributes earns a place in the doc while nobody at all is prepared to make a practice statement about how many superusers is good. I’d like very much to understand the critical parts that I’m missing of the essential mental model in this general space.
