Re: CREATEROLE and role ownership hierarchies

From: "Bossart, Nathan" <bossartn(at)amazon(dot)com>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Cc: Andrew Dunstan <andrew(at)dunslane(dot)net>
Subject: Re: CREATEROLE and role ownership hierarchies
Date: 2021-10-21 23:04:34
Message-ID: AA235A50-0AFE-4757-B2C8-51C94EBBBC7F@amazon.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 10/20/21, 11:46 AM, "Mark Dilger" <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
> The purpose of these patches is to fix the CREATEROLE escalation
> attack vector misfeature. (Not everyone will see CREATEROLE that
> way, but the perceived value of the patch set likely depends on how
> much you see CREATEROLE in that light.)

Regarding the "attack vector misfeature" comment, I remember being
surprised when I first learned how much roles with CREATEROLE can do.
When I describe CREATEROLE to others, I am sure to emphasize the note
in the docs about such roles being "almost-superuser" roles.
CREATEROLE is a rather big hammer at the moment, so I certainly think
there is value in reducing its almost-superuser-ness.

I mentioned this in the other thread [0] already, but the first thing
that comes to mind when I look at these patches is how upgrades might
work. Will we just make the bootstrap superuser the owner for all
roles when you first upgrade to v15? Also, are we just going to strip
the current CREATEROLE roles of much of their powers? Maybe it's
worth keeping a legacy CREATEROLE role attribute for upgraded clusters
that could eventually be removed down the road.

I'd also like to bring up my note about allowing users to transfer
role ownership. When I tested the patches earlier, REASSIGN OWNED BY
was failing with an "unexpected classid" ERROR. Besides REASSIGN
OWNED BY, perhaps there should be another mechanism for transferring
ownership on a role-by-role basis (i.e., ALTER ROLE OWNER TO). I
haven't looked at this new patch set too closely, so my apologies if
this has already been added.

Nathan

[0] https://postgr.es/m/53C7DF4C-8463-4647-9DFD-779B5E1861C4%40amazon.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bossart, Nathan 2021-10-21 23:13:11 Re: Experimenting with hash tables inside pg_dump
Previous Message Tom Lane 2021-10-21 22:27:25 Experimenting with hash tables inside pg_dump