On Mon, 2022-06-27 at 23:36 +0200, Hannu Krosing wrote:
> My current thinking is (based on more insights from Andres) that we
> should also have a startup flag to disable superuser altogether to
> avoid bypasses via direct manipulation of pg_proc.
What do you mean by "disable superuser altogether"? What about SECURITY
DEFINER functions, or extension install scripts, or background workers
created by extensions?
Do you mean prevent logging in as superuser and prevent SET ROLE to
superuser? What if a user *becomes* superuser in the middle of a
session?
If we go down this road, I wonder if we should reconsider the idea of
changing superuser status of an existing role. Changing superuser
status already creates some weirdness. We could go so far as to say you
can only create/drop superusers via a tool or config file when the
server is shut down.
I don't think I've ever used more than a couple superusers, and I don't
think I've had a good reason to change superuser status of an existing
user before, except as a hack to have non-superuser-owned
subscriptions. There are probably better solutions to that problem. [CC
Mark as he may be interested in this discussion.]
Regards,
Jeff Davis
