On 11/21/22 15:05, Bryn Llewellyn wrote:
adrian.kla...@aklaver.com wrote:
...why the "Nobody supports it!" statement for a recommendation that only
appeared at the same time? I for one have a poor record of mind reading and/or predicting
the future:)
Here’s what I wrote in the post that started this thread, archived at this URL:
https://www.postgresql.org/message-id/290ef7b8-d150-4ae1-8ffe-a38912cd1...@yugabyte.com
The implication is clear: you should allow a cluster to have just a single
superuser, the inevitable bootstrap superuser, and you should think very carefully
indeed before ever starting a session as this role because of the risks that doing
so brings. Rather, you should realize that there are hardly any tasks that cannot be
carried out by an appropriately configured role with "nosuperuser”.
The essential content of each (what I wrote in my opening post and what stands
between « ... » above) is the same: allow maximum one superuser. Each is a
strawman. And, as such, carries its own implicit invitation for challenge or
support. The outcome was all challenge and no support. I don’t know why
observing that this was the outcome has, itself, become controversial.
You must be reading a different thread. What I saw in the replies was
people answering '...is there ever a use case to have two or more
superusers?' with, maybe but in the end it is up to you to decide what
works in your case.
In fact, David Johnston did unequivocally challenge my strawman a couple of
turns back, thus:
no one is supposed to login to the database cluster using the postgres role.
Period. Upon initialization whomever is responsible for creating the cluster
gets their personal user credentials installed into the cluster as superuser
and from that point on never uses postgres.
You left out the preface to the above, 'My policy would be that ...`
And the equivocal additions later in the post:
"I suppose the suggestion I would be willing to consider is: only have
the postgres superuser, never grant superuser to login roles explicitly,
instead if those persons require superuser grant them membership in the
postgres role."
and
"
So yes I, like everyone else, is going to end up forming their own
generalities. Ideas that I cannot wholly discredit as bad, but that
don't fit into my generality, get the "if the specific circumstances
warrant it" treatment. My own presuppositions ultimately should get the
same treatment by whomever is implementing such policies."
That’s actionable advice. I mentioned that I had implemented that scheme and
then, later, abandoned it. I can easily re-implement it.
Because PG allows a cluster to have as many superusers as you please, and
because any one of these can create or drop another, any convention in this
space needs some extra mechanisms to enforce it..
I believe that the fact that a superuser's ability to start a session can be limited by what the
"hba_file" says is critical here—together with the fact that the ability to edit this
file is governed by the regime of O/S users and file privileges. Maybe this is the key to the
effectively tamper-proof implementation of the scheme that David recommends. (Having said this,
there's always the "set role" backdoor.)
There's also the caveat that a "drop" attempt by a superuser for a single object owned by the
bootstrap superuser (say, the "pg_catalog.pg_terminate_backend()" function) in some database causes
an error with the message "cannot drop function... because it is required by the database system".
(At least, this is what my tests have shown with a smallish sample of drop targets.) This seems to be a Very
Good Thing. But the fact that this is the behavior makes me wonder what harm can be done by a session that
authorizes as the bootstrap superuser that cannot be done by a session that authorizes as a regular
superuser. I'll try to find out.
Superuser is superuser, there is no magic associated with the bootstrap
superuser.
FYI, the answer is won't make a difference.
--
Adrian Klaver
adrian.kla...@aklaver.com
