> adrian.klaver@aklaver.com wrote:
>
>> Karsten.Hilbert@gmx.net:
>>
>>> adrian.klaver@aklaver.com wrote:
>>>
>>>> bryn@yugabyte.com
>>>>
>>>> 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
stipulationis 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,
DavidJohnston 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
thenuse this role for all routine management of databases and roles. This approach avoids the dangers of operating as a
superuserfor 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
sayingsomething “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
bootstrapsuperuser. This recognizes the fact that, once the initial configuration of a cluster has been done
immediatelyafter its creation (which configuration is done while still in self-imposed single-user mode), there are
thenvery 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
thedoc while nobody at all is prepared to make a practice statement about how many superusers is good. I’d like very
muchto understand the critical parts that I’m missing of the essential mental model in this general space.