Re: [EXTERNAL] Re: [PATCH] Support using "all" for the db user in pg_ident.conf
Jelte Fennema-Nio <postgres@jeltef.nl>
From: Jelte Fennema <postgres@jeltef.nl>
To: Michael Paquier <michael@paquier.xyz>
Cc: Jelte Fennema <Jelte.Fennema@microsoft.com>, "isaac.morland@gmail.com" <isaac.morland@gmail.com>, "pgsql-hackers@lists.postgresql.org" <pgsql-hackers@lists.postgresql.org>, Nathan Bossart <nathandbossart@gmail.com>,
Andrew Dunstan <andrew@dunslane.net>
Date: 2023-01-11T14:22:35Z
Lists: pgsql-hackers
Attachments
- v3-0004-Support-same-user-patterns-in-pg_ident.conf-as-in.patch (application/octet-stream) patch v3-0004
- v3-0002-Store-pg_user-as-AuthToken-in-IdentLine.patch (application/octet-stream) patch v3-0002
- v3-0003-Only-expand-1-in-pg_ident.conf-when-not-quoted.patch (application/octet-stream) patch v3-0003
- v3-0001-Make-naming-in-code-for-username-maps-consistent.patch (application/octet-stream) patch v3-0001
> couldn't we also use a regexp for the pg-role rather than > just a hardcoded keyword here then, so as it would be possible to > allow a mapping to pass for a group of role names? "all" is just a > pattern to allow everything, at the end. That's a good point. I hadn't realised that you added support for regexes in pg_hba.conf in 8fea868. Attached is a patchset where I reuse the pg_hba.conf code path to add support to pg_ident.conf for: all, +group and regexes. The main uncertainty I have is if the case insensitivity check is actually needed in check_role. It seems like a case insensitive check against the database user shouldn't actually be necessary. I only understand the need for the case insensitive check against the system user. But I have too little experience with LDAP/kerberos to say for certain. So for now I kept the existing behaviour to not regress. The patchset also contains 3 preparatory patches with two refactoring passes and one small bugfix + test additions. > - renaming "systemuser" to "system_user_token" to outline that this is > not a simple string but an AuthToken with potentially a regexp? I decided against this, since now both system user and database user are tokens. Furthermore, compiler warnings should avoid any confusion against using this as a normal string. If you feel strongly about this though, I'm happy to change this. On Wed, 11 Jan 2023 at 14:34, Michael Paquier <michael@paquier.xyz> wrote: > > On Wed, Jan 11, 2023 at 09:04:56AM +0000, Jelte Fennema wrote: > > It's very different. I think easiest is to explain by example: > > > > If there exist three users on the postgres server: admin, jelte and michael > > > > Then this rule (your suggested rule): > > mapname /^(.*)$ \1 > > > > Is equivalent to: > > mapname admin admin > > mapname jelte jelte > > mapname michael michael > > > > While with the "all" keyword you can create a rule like this: > > mapname admin all > > > > which is equivalent to: > > mapname admin admin > > mapname admin jelte > > mapname admin michael > > Thanks for the explanation, I was missing your point. Hmm. On top > of my mind, couldn't we also use a regexp for the pg-role rather than > just a hardcoded keyword here then, so as it would be possible to > allow a mapping to pass for a group of role names? "all" is just a > pattern to allow everything, at the end. > -- > Michael
Commits
-
Add description for new patterns supported in HBA and ident sample files
- 1b43743f1174 16.0 landed
-
Support the same patterns for pg-user in pg_ident.conf as in pg_hba.conf
- efb6f4a4f9b6 16.0 landed
-
Track behavior of \1 in pg_ident.conf when quoted
- 0b717432ff13 16.0 landed
-
Store IdentLine->pg_user as an AuthToken
- 02d3448f4f79 16.0 landed
-
Add tests for regex replacement with \1 in pg_ident.conf to 0003_peer.pl
- e753ae6397fe 16.0 landed
-
Rename some variables related to ident files in hba.{c,h}
- 8607630d74cd 16.0 landed