Re: Allow +group in pg_ident.conf - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Allow +group in pg_ident.conf
Date
Msg-id Y7y8BVRHFvXXKJEJ@paquier.xyz
Whole thread Raw
In response to Re: Allow +group in pg_ident.conf  (Andrew Dunstan <andrew@dunslane.net>)
List pgsql-hackers
On Mon, Jan 09, 2023 at 05:33:14PM -0500, Andrew Dunstan wrote:
> I've adapted a sentence from the pg_hba.conf documentation so we stay
> consistent.

+  <para>
+   If the <replaceable>database-username</replaceable> begins with a
+   <literal>+</literal> character, then the operating system user can login as
+   any user belonging to that role, similarly to how user names beginning with
+   <literal>+</literal> are treated in <literal>pg_hba.conf</literal>.
+   Thus, a <literal>+</literal> mark means <quote>match any of the roles that
+   are directly or indirectly members of this role</quote>, while a name
+   without a <literal>+</literal> mark matches only that specific role.
+  </para>

Should this also mention that the behavior is enforced even in cases
where we expect a case-sensitive match?

> It's not really relevant. We're not comparing role names here; rather we
> look up two roles and then ask if one is a member of the other. I've
> added a comment.
>
> Thanks for the review (I take it you're generally in favor).

-       if (case_insensitive)
+       if (regexp_pgrole[0] == '+')
+       {
+           /*
+            * Since we're not comparing role names here, use of case
+            * insensitive matching doesn't really apply.
+            */
+           Oid roleid = get_role_oid(pg_role, true);
+           Assert(false);
+           if (is_member(roleid, regexp_pgrole +1))
+               *found_p = true;
+       }
+       else if (case_insensitive)

Hmm.  As check_ident_usermap() is now coded, it means that the case of
a syntax substitution could be enforced to use a group with the user
name given by the client.  For example, take this ident entry:
mymap   /^(.*)@mydomain\.com$      \1

Then, if we attempt to access Postgres with "+testrole@mydomain.com",
we would get a substitution to "+testrole", which would be enforced to
check on is_member() with this expected role name.  I am not sure what
should be the correct behavior here.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: POC: Lock updated tuples in tuple_update() and tuple_delete()
Next
From: Andres Freund
Date:
Subject: Re: Decoupling antiwraparound autovacuum from special rules around auto cancellation