From: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com> |
---|---|
To: | Noah Misch <noah(at)leadboat(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Tying an object's ownership to datdba |
Date: | 2021-03-24 15:57:37 |
Message-ID: | CAFBsxsGf2uDCH3FDqKNQN5x67X60q=sjU3YBDbVFDnDnXo2BAQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Dec 28, 2020 at 12:32 AM Noah Misch <noah(at)leadboat(dot)com> wrote:
> [v2]
Hi Noah,
In the refactoring patch, there is a lingering comment reference to
roles_has_privs_of(). Aside from that, it looks good to me. A possible
thing to consider is an assert that is_admin is not null where we expect
that.
The database owner role patch looks good as well.
> I ended up blocking DDL that creates role memberships involving the new
role;
> see reasons in user.c comments. Lifting those restrictions looked
feasible,
> but it was inessential to the mission, and avoiding unintended
consequences
> would have been tricky. Views "information_schema.enabled_roles" and
> "information_schema.applicable_roles" list any implicit membership in
> pg_database_owner, but pg_catalog.pg_group and psql \dgS do not. If this
> leads any reviewer to look closely at applicable_roles, note that its
behavior
> doesn't match its documentation
> (https://postgr.es/m/flat/20060728170615(dot)GY20016(at)kenobi(dot)snowman(dot)net)
Is this something that needs fixing separately?
--
John Naylor
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-03-24 16:01:15 | Re: default result formats setting |
Previous Message | Jacob Champion | 2021-03-24 15:54:52 | Re: Support for NSS as a libpq TLS backend |