Horton

Re: fixing CREATEROLE

David G. Johnston <david.g.johnston@gmail.com>

View thread View on postgr.es
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Mark Dilger <mark.dilger@enterprisedb.com>, walther@technowledgy.de, Tom Lane <tgl@sss.pgh.pa.us>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-11-28T21:19:35Z
Lists: pgsql-hackers 
On Mon, Nov 28, 2022 at 1:28 PM Robert Haas <robertmhaas@gmail.com> wrote:

> On Mon, Nov 28, 2022 at 3:02 PM Mark Dilger
> <mark.dilger@enterprisedb.com> wrote:
>

> You can argue that a grant with INHERIT FALSE, SET FALSE, ADMIN TRUE
> still grants membership, and I think formally that's true, but I also
> think it's just picking something to bicker about. The need isn't to
> separate membership per se from administration. It's to separate
> privilege inheritance and the ability to SET ROLE from role
> administration. And I've done that.
>

We seem to now be in agreement on this design choice, and the related bit
about bootstrap superuser granting admin on newly created roles by the
createrole user.

This seems like a patch in its own right.

It still leaves open the default membership behavior as well as whether we
want to rework the attributes into predefined roles.


> I strongly disagree with the idea that the ability for users to
> control defaults here isn't needed.


That's fine, but are you saying this patch is incapable (or simply
undesirable) of having the parts about handling defaults separated out from
the parts that define how the system works with a given set of permissions;
and the one implementation detail of having the bootstrap superuser
automatically grant admin to any roles a createuser role creates? If you
and others feel strongly about defaults I'm sure that the suggested other
thread focused on that will get attention and be committed in a timely
manner.  But the system will work, and not be broken, if that got stalled,
and it could be added in later.

David J.

Commits

  1. Add new GUC createrole_self_grant.

  2. Restrict the privileges of CREATEROLE users.

  3. Pass down current user ID to AddRoleMems and DelRoleMems.

  4. Refactor permissions-checking for role grants.

  5. Improve documentation of the CREATEROLE attibute.

  6. Make role grant system more consistent with other privileges.