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 |
Message-ID: | Yz+Jt9537vjfO733@paquier.xyz |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
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
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
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 |