Re: role self-revocation

On Thu, Mar 10, 2022 at 3:01 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Thu, Mar 10, 2022 at 4:00 PM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> > I dislike changing the documented behavior of CREATEROLE to the degree
> suggested here. However, there are three choices here, only one of which
> can be chosen:
> >
> > 1. Leave CREATEROLE alone entirely
> > 2. Make it so CREATEROLE cannot assign membership to the predefined
> roles or superuser (inheritance included), but leave the rest alone. This
> would be the hard-coded version, not the role attribute one.
> > 3. Make it so CREATEROLE can only assign membership to roles for which
> it has been made an admin; as well as the other things mentioned
> >
> > Moving forward I'd prefer options 1 or 2, leaving the ability to
> create/alter/drop a role to be vested via predefined roles.
>
> It sounds like you prefer a behavior where CREATEROLE gives power over
> all non-superusers, but that seems pretty limiting to me.
>

Doh! I edited out the part where I made clear I considered options 1 and 2
as basically being done for a limited period of time while deprecating the
CREATEROLE attribute altogether in favor of the fine-grained and predefined
role based permission granting. I don't want to nerf CREATEROLE as part of
adding this new feature, instead leave it as close to status quo as
reasonable so as not to mess up existing setups that make use of it. We
can note in the release notes and documentation that we consider CREATEROLE
to be deprecated and that the new predefined role should be used to give a
user the ability to create/alter/drop roles, etc... DBAs should consider
revoking CREATEROLE from their users and granting them proper memberships
in the predefined roles and the groups those roles should be administering.

David J.