Re: CREATEROLE and role ownership hierarchies

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: Stephen Frost <sfrost(at)snowman(dot)net>, Andrew Dunstan <andrew(at)dunslane(dot)net>, "Bossart, Nathan" <bossartn(at)amazon(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Shinya Kato <Shinya11(dot)Kato(at)oss(dot)nttdata(dot)com>
Subject: Re: CREATEROLE and role ownership hierarchies
Date: 2022-02-02 20:49:48
Message-ID: CA+TgmoZHN2Z48U2j5BOLc9w1=Ny9XkhHrc0QYSsbuGD8_y2cGQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Feb 2, 2022 at 3:23 PM Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com> wrote:
> It's perfectly reasonable (in my mind) that Robert, acting as superuser, may want to create a creator who acts like a superuser over the sandbox, while at the same time Stephen, acting as superuser, may want to create a creator who acts as a low privileged bot that only adds and removes roles, but cannot read their tables, SET ROLE to them, etc.
>
> I don't see any reason that Robert and Stephen can't both get what they want. We just have to make Thing 1 flexible enough.

Hmm, that would be fine with me. I don't mind a bit if other people
get what they want, as long as I can get what I want, too! In fact,
I'd prefer it if other people also get what they want...

That having been said, I have some reservations if it involves tightly
coupling new features that we're trying to add to existing things that
may or may not be that well designed, like the role-level INHERIT
flag, or WITH ADMIN OPTION, or the not-properly maintained
pg_auth_members.grantor column, or even the SQL standard. I'm not
saying we should ignore any of those things and I don't think that we
should ... but at the same time, we can't whether the feature does
what people want it to do, either. If we do, this whole thing is
really a complete waste of time. If a patch achieves infinitely large
amounts of backward compatibility, standards compliance, and
conformity with existing design but doesn't do the right stuff, forget
it!

--
Robert Haas
EDB: http://www.enterprisedb.com

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2022-02-02 21:08:04 Re: Support for NSS as a libpq TLS backend
Previous Message Peter Geoghegan 2022-02-02 20:38:51 Re: Why is INSERT-driven autovacuuming based on pg_class.reltuples?