Re: Tying an object's ownership to datdba

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

In response to

Responses

Browse pgsql-hackers by date

  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