On 02.06.22 18:26, Robert Haas wrote:
On Mon, Feb 7, 2022 at 11:13 AM Joe Conway<m...@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.
