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.
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 |