Re: [PATCH] Support using "all" for the db user in pg_ident.conf

From: Michael Paquier <michael(at)paquier(dot)xyz>
To: Jelte Fennema <Jelte(dot)Fennema(at)microsoft(dot)com>
Cc: "isaac(dot)morland(at)gmail(dot)com" <isaac(dot)morland(at)gmail(dot)com>, "pgsql-hackers(at)lists(dot)postgresql(dot)org" <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: [PATCH] Support using "all" for the db user in pg_ident.conf
Date: 2023-01-11 05:27:09
Message-ID: Y75IrYUnHTOrlEZ+@paquier.xyz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Dec 28, 2022 at 09:11:05AM +0000, Jelte Fennema wrote:
> That's totally fair, I attached a new iteration of this patchset where this
> refactoring and the new functionality are split up in two patches.

The confusion that 0001 is addressing is fair (cough, fc579e1, cough),
still I am wondering whether we could do a bit better to be more
consistent with the lines of the ident file, as of:
- renaming "pg_role" to "pg_user", as we use pg-username or
database-username when referring to it in the docs or the conf sample
file.
- renaming "systemuser" to "system_user_token" to outline that this is
not a simple string but an AuthToken with potentially a regexp?
- Changing the order of the elements in IdentLine to map with the
actual ident lines: usermap, systemuser and pg_user.

> I'm not sure if I'm understanding your concern correctly, but
> the system username will still be compared case sensitively if requested.
> The only thing this changes is that: before comparing the pg_role
> column to the requested pg_role case sensitively, it now checks if
> the value of the pg_role column is lowercase "all". If that's the case,
> then the pg_role column is not compared to the requested
> pg|role anymore, and instead access is granted.

Yeah, still my spider sense reacts on this proposal, and I think that
I know why.. In what is your proposal different from the following
entry in pg_ident.conf? As of:
mapname /^(.*)$ \1

This would allow everything, and use for the PG user the same user as
the one provided by the client. That's what your proposal with "all"
does, no? The heart of the problem is that you still require PG roles
that have a 1:1 mapping the user names provided by the clients.
--
Michael

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2023-01-11 05:36:17 Re: Spinlock is missing when updating two_phase of ReplicationSlot
Previous Message David Rowley 2023-01-11 05:23:50 Re: Add proper planner support for ORDER BY / DISTINCT aggregates