Re: fixing CREATEROLE

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, walther(at)technowledgy(dot)de, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fixing CREATEROLE
Date: 2022-11-28 23:31:49
Message-ID: CAKFQuwY4butiu_6-tt63mEMmorad2bnsmrbTE6F=9pqwzuk=tg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Nov 28, 2022 at 2:55 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> On Mon, Nov 28, 2022 at 4:19 PM David G. Johnston
> <david(dot)g(dot)johnston(at)gmail(dot)com> wrote:
> > 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.
>
> The topics are so closely intertwined that I don't believe that trying
> to have separate discussions will be useful or productive. There's no
> hope of anybody understanding 0004 or having an educated opinion about
> it without first understanding the earlier patches, and there's no
> requirement that someone has to review 0004, or like it, just because
> they review or like 0001-0003.
>
> But so far nobody has actually reviewed anything

> Well, if that's the case, then why
> did we have hundreds and hundreds of emails within the last 12 months
> arguing about which way it should work?
>
>
When ya'll come to some final conclusion on how you want the defaults to
look, come tell the rest of us. You already have 4 people debating the
matter, I don't really see the point of adding more voices to that
cachopany. As you noted - voicing an opinion about 0004 is optional.

I'll reiterate my review from before, with a bit more confidence this time.

0001-0003 implements a desirable behavior change. In order for someone to
make some other role a member in some third role that someone must have
admin privileges on both other roles. CREATEROLE is not exempt from this
rule. A user with CREATEROLE will, upon creating a new role, be granted
admin privilege on that role by the bootstrap superuser.

The consequence of 0001-0003 in the current environment is that since the
newly created CREATEROLE user will not have admin rights on any existing
roles in the cluster, while they can create new roles in the system they
are unable to grant those new roles membership in any other roles not also
created by them. The ability to assign attributes to newly created roles
is unaffected.

As a unit of work, those are "ready-to-commit" for me. I'll leave it to
you and others to judge the technical quality of the patch and finishing up
the FIXMEs that have been noted.

Desirable follow-on patches include:

1) Automatically install an additional membership grant, with the
CREATEROLE user as the grantor, specifying INHERIT OR SET as TRUE (I
personally favor attaching these to ALTER ROLE, modifiable only by oneself)

2) Convert Attributes into default roles

David J.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Nathan Bossart 2022-11-28 23:40:39 Re: O(n) tasks cause lengthy startups and checkpoints
Previous Message Michael Paquier 2022-11-28 23:24:47 Re: Report roles in pg_upgrade pg_ prefix check