Re: use has_privs_of_role() for pg_hba.conf

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Nathan Bossart <nathandbossart(at)gmail(dot)com>
Cc: Joe Conway <mail(at)joeconway(dot)com>, Joshua Brindle <joshua(dot)brindle(at)crunchydata(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: use has_privs_of_role() for pg_hba.conf
Date: 2022-10-07 02:06:47
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: 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

+$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 instead? It would be cheaper.

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Smith 2022-10-07 02:15:22 create subscription - improved warning message
Previous Message Michael Paquier 2022-10-07 01:30:28 Re: Record SET session in VariableSetStmt