sql: Remove inheritance of role attributes #18779
Conversation
Previously, roles inherited role attributes of all their member roles. This was incorrect and not has PostgreSQL works. This commit removes this inheritance. Part of #11579
jkosh44
force-pushed
the
role-attribute-member-fix
branch
from
982171e
to
86da1c3
Compare
| @@ -145,8 +145,9 @@ pub fn check_plan( | |||
| } | |||
|
|
|||
| // Validate that the current session has the required attributes to execute the provided plan. | |||
| // Note: role attributes are not inherited by role membership. | |||
There was a problem hiding this comment.
Wait what? Is this because of NOINHERIT or something? I'm reading over https://www.postgresql.org/docs/current/role-membership.html but don't see what's going on here.
There was a problem hiding this comment.
No, I just originally misunderstood role attributes. They are never inherited, unlike role privileges and object ownership. If you scroll down to the end of those docs you'll see:
The role attributes LOGIN, SUPERUSER, CREATEDB, and CREATEROLE can be thought of as special privileges, but they are never inherited as ordinary privileges on database objects are. You must actually SET ROLE to a specific role having one of these attributes in order to make use of the attribute. Continuing the above example, we might choose to grant CREATEDB and CREATEROLE to the admin role. Then a session connecting as role joe would not have these privileges immediately, only after doing SET ROLE admin.
Previously, roles inherited role attributes of all their member roles. This was incorrect and not has PostgreSQL works. This commit removes this inheritance. Part of #11579
Previously, roles inherited role attributes of all their member roles. This was incorrect and not has PostgreSQL works. This commit removes this inheritance.
Part of MaterializeInc/database-issues#3380
Motivation
This PR adds a known-desirable feature.
Checklist
$T ⇔ Proto$Tmapping (possibly in a backwards-incompatible way) and therefore is tagged with aT-protolabel.