Re: CREATEROLE and role ownership hierarchies - Mailing list pgsql-hackers

From Robert Haas
Subject Re: CREATEROLE and role ownership hierarchies
Date
Msg-id CA+TgmoZHN2Z48U2j5BOLc9w1=Ny9XkhHrc0QYSsbuGD8_y2cGQ@mail.gmail.com
Whole thread Raw
In response to Re: CREATEROLE and role ownership hierarchies  (Mark Dilger <mark.dilger@enterprisedb.com>)
Responses Re: CREATEROLE and role ownership hierarchies  (Maciek Sakrejda <m.sakrejda@gmail.com>)
List pgsql-hackers
On Wed, Feb 2, 2022 at 3:23 PM Mark Dilger <mark.dilger@enterprisedb.com> wrote:
> It's perfectly reasonable (in my mind) that Robert, acting as superuser, may want to create a creator who acts like a
superuserover the sandbox, while at the same time Stephen, acting as superuser, may want to create a creator who acts
asa 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



pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: Why is INSERT-driven autovacuuming based on pg_class.reltuples?
Next
From: Bruce Momjian
Date:
Subject: Re: Support for NSS as a libpq TLS backend