Re: Proposal: allow database-specific role memberships

Kenaniah Cerny <kenaniah(at)gmail(dot)com> wrote:

> Attached is a newly-rebased patch -- would love to get a review from someone whenever possible.

I've picked this patch for a review. The patch currently does not apply to the
master branch, so I could only read the diff. Following are my comments:

* I think that roles_is_member_of() deserves a comment explaining why the code
that you moved into append_role_memberships() needs to be called twice,
i.e. once for global memberships and once for the database-specific ones.

I think the reason is that if, for example, role "A" is a database-specific
member of role "B" and "B" is a "global" member of role "C", then "A" should
not be considered a member of "C", unless "A" is granted "C" explicitly. Is
this behavior intended?

Note that in this example, the "C" members are a superset of "B" members,
and thus "C" should have weaker permissions on database objects than
"B". What's then the reason to not consider "A" a member of "C"? If "C"
gives its members some permissions of "B" (e.g. "pg_write_all_data"), then I
think the roles hierarchy is poorly designed.

A counter-example might help me to understand.

* Why do you think that "unsafe_tests" is the appropriate name for the
directory that contains regression tests?

I can spend more time on the review if the patch gets rebased.

--
Antonin Houska
Web: https://www.cybertec-postgresql.com