Re: replacing role-level NOINHERIT with a grant-level option

On 02.06.22 18:26, Robert Haas wrote:
> On Mon, Feb 7, 2022 at 11:13 AM Joe Conway<mail@joeconway.com>  wrote:
>>> It seems to me that the INHERIT role flag isn't very well-considered.
>>> Inheritance, or the lack of it, ought to be decided separately for
>>> each inherited role. However, that would be a major architectural
>>> change.
>> Agreed -- that would be useful.
> Is this a kind of change people would support?

I think this would create a conflict with what role-based access control 
normally means (outside of PostgreSQL specifically).  A role is a 
collection of privileges that you dynamically enable (e.g., with SET 
ROLE).  That corresponds to the NOINHERIT behavior.  It's also what the 
SQL standard specifies (which in term references other standards for 
RBAC).  The INHERIT behavior basically emulates the groups that used to 
exist in PostgreSQL.

There are also possibly other properties you could derive from that 
distinction.  For example, you could  argue that something like 
pg_hba.conf should have group matching but not (noinherit-)role 
matching, since those roles are not actually activated all the time.

There are also more advanced concepts like roles that are mutually 
exclusive so that you can't activate them both at once.

Now, what PostgreSQL currently implements is a bit of a mess that's a 
somewhat incompatible subset of all that.  But you can basically get 
those standard behaviors somehow.  So I don't think we should break this 
and go into a totally opposite direction.