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