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: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: fixing CREATEROLE
Date: 2022-11-23 21:19:20
Message-ID: CAKFQuwZYsfKKBEFUZhZ8FrKPHooscVuMXUYAMohgpe5nJeTKvw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Nov 23, 2022 at 2:01 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:

> In the latter case there are two, one with
>
> grantor=bootstrap_supeuser/admin_option=true/set_option=false/inherit_option=false
> and a second with
> grantor=alice/admin_option=false/set_option=true/inherit_option=true.
>

This, IMO, is preferable. And I'd probably typically want to hide the
first grant from the user in typical cases - it is an implementation detail.

We have to grant the creating role membership in the created role, with
admin option, as a form of bookkeeping.

If the creating role really wants to be a member of the created role for
other reasons that should be done explicitly and granted by the creating
role.

This patch series need not be concerned about how easy or difficult it is
to get the additional grant entry into the database. The ability to refine
the permissions in the data model is there so there should be no complaints
that "it is impossible to set up this combination of permissions". We've
provided a detailed model and commands to alter it - the users can build
their scripts to glue those things together.

David J.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message samay sharma 2022-11-23 21:24:51 Re: Documentation for building with meson
Previous Message Tom Lane 2022-11-23 21:18:08 Re: fixing CREATEROLE