If role A is a direct or indirect member of role B but does not inherit B's privileges (because at least one relevant grant was created WITH INHERIT FALSE) then A should not be permitted to bypass privilege checks that require the privileges of B. For example, A can't change the privileges of objects owned by B, nor can A drop those objects.
However, up until now, it's been possible for A to change default privileges for role B. That doesn't seem to be correct, because a non-inherited role grant is only supposed to permit you to assume the identity of the granted role via SET ROLE, and should not otherwise permit you to exercise the privileges of that role. Most places followed that rule, but this case was an exception.
This could be construed as a security vulnerability, but it does not seem entirely clear cut, since older branches were fuzzy about the distinction between is_member_of_role() and has_privs_of_role() in a number of other ways as well. Because of this, and because user-visible behavior changes in minor releases are to be avoided whenever possible, no back-patch.
48a257d444 Make ALTER DEFAULT PRIVILEGES require privileges, not membership.
src/backend/catalog/aclchk.c | 11 ++++-------
1 file changed, 4 insertions(+), 7 deletions(-)