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 21:19:35
Message-ID: CAKFQuwZYVLcigUd6y5pMDiNLgfmeZ2Yn+B+AFe7odaPnDAn3=A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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

> On Mon, Nov 28, 2022 at 3:02 PM Mark Dilger
> <mark(dot)dilger(at)enterprisedb(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2022-11-28 21:23:27 Re: [PATCH] Infinite loop while acquiring new TOAST Oid
Previous Message Robert Haas 2022-11-28 21:10:01 Re: Bug in wait time when waiting on nested subtransaction