Re: use has_privs_of_role() for pg_hba.conf - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: use has_privs_of_role() for pg_hba.conf
Date
Msg-id Yz+Jt9537vjfO733@paquier.xyz
Whole thread Raw
In response to Re: use has_privs_of_role() for pg_hba.conf  (Nathan Bossart <nathandbossart@gmail.com>)
Responses Re: use has_privs_of_role() for pg_hba.conf  (Nathan Bossart <nathandbossart@gmail.com>)
List pgsql-hackers
On Thu, Oct 06, 2022 at 10:43:43AM -0700, Nathan Bossart wrote:
> Here is a new version of the patch with a test.

Thanks, that helps a lot.  Now I grab the difference even if your
previous patch was already switching the documentation to tell exactly
that.  On the ground of 6198420, it looks indeed strange to not do the
same for pg_hba.conf.  That makes the whole story more consistent, for
one.

+$node->safe_psql('postgres', "CREATE DATABASE role1;");
+$node->safe_psql('postgres', "CREATE ROLE role1 LOGIN PASSWORD 'pass';");
+$node->safe_psql('postgres', "CREATE ROLE role2 LOGIN SUPERUSER INHERIT IN ROLE role1 PASSWORD 'pass';");
+$node->safe_psql('postgres', "CREATE ROLE role3 LOGIN SUPERUSER NOINHERIT IN ROLE role1 PASSWORD 'pass';");
So this comes down to role3, where HEAD allows a connection as long as
it is a member of role1 for +role1, samegroup and samerole, but the
patch would prevent the connection when role3 does not inherit the
permissions of role1, even if it is a superuser.

samegroup is a synonym of samerole, but fine by me to keep the full
coverage and all three sets.

Rather than putting that in a separate script, which means
initializing a new node, etc. could it be better to put that in
001_password.pl instead?  It would be cheaper.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Record SET session in VariableSetStmt
Next
From: Peter Smith
Date:
Subject: create subscription - improved warning message