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

Greetings,

On Fri, Jun 10, 2022 at 16:36 Peter Eisentraut <
peter(dot)eisentraut(at)enterprisedb(dot)com> wrote:

> On 02.06.22 18:26, Robert Haas wrote:
> > On Mon, Feb 7, 2022 at 11:13 AM Joe Conway<mail(at)joeconway(dot)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.

Based on the later discussion, I don’t think anyone is really advocating to
move away from having a concept of immediately-inherited rights (inherit)
or to remove SET ROLE, or even to really change how they work all that
much. The idea is to give admins to control these with more granularity.

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.

This might be an interesting thing to consider separating out as a distinct
property, or we could just define it to depend on an existing other
property (which is essentially what is done today).

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

That’s an interesting one to consider and might be relevant to Robert’s
thoughts on how to extend GRANT.

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.

Not sure how this is totally opposite.

Thanks,

Stephen

>