Re: fixing CREATEROLE

Mark Dilger <mark.dilger@enterprisedb.com>

From: Mark Dilger <mark.dilger@enterprisedb.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2022-11-22T22:48:47Z
Lists: pgsql-hackers

> On Nov 22, 2022, at 2:02 PM, Robert Haas <robertmhaas@gmail.com> wrote:
> 
>> Patch 0004 feels like something that won't get committed.  The INHERITCREATEDROLES and SETCREATEDROLES in 0004 seems clunky.
> 
> I think role properties are kind of clunky in general, the way we've
> implemented them in PostgreSQL, but I don't really see why these are
> worse than anything else. I think we need some way to control the
> behavior, and I don't really see a reasonable place to put it other
> than a per-role property. And if we're going to do that then they
> might as well look like the other properties that we've already got.
> 
> Do you have a better idea?

Whatever behavior is to happen in the CREATE ROLE statement should be spelled out in that statement.  "CREATE ROLE bob WITH INHERIT false WITH SET false" doesn't seem too unwieldy, and has the merit that it can be read and understood without reference to hidden parameters.  Forcing this to be explicit should be safer if these statements ultimately make their way into dump/restore scripts, or into logical replication.

That's not to say that I wouldn't rather that it always work one way or always the other.  It's just to say that I don't want it to work differently based on some poorly advertised property of the role executing the command.

—
Mark Dilger
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company






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.