On Wed, Jan 11, 2023 at 03:22:35PM +0100, Jelte Fennema wrote: > 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.
if (!identLine->pg_user->quoted &&
+ identLine->pg_user->string[0] != '+' &&
+ !token_is_keyword(identLine->pg_user, "all") &&
+ !token_has_regexp(identLine->pg_user) &&
If we finish by allowing a regexp for the PG user in an IdentLine, I
would choose to drop "all" entirely. Simpler is better when it comes
to authentication, though we are working on getting things more..
Complicated.
+ Quoting a <replaceable>database-username</replaceable> containing
+ <literal>\1</literal> makes the <literal>\1</literal>
+ lose its special meaning.
0002 and 0003 need careful thinking.
+# Success as the regular expression matches and \1 is replaced
+reset_pg_ident($node, 'mypeermap', qq{/^$system_user(.*)\$},
+ 'test\1mapuser');
+test_role(
+ $node,
+ qq{testmapuser},
+ 'peer',
+ 0,
+ 'with regular expression in user name map with \1',
+ log_like =>
+ [qr/connection authenticated: identity="$system_user" method=peer/]);
Relying on kerberos to check the substitution pattern is a bit
annoying.. I would be really tempted to extract and commit that
independently of the rest, actually, to provide some coverage of the
substitution case in the peer test.
> The patchset also contains 3 preparatory patches with two refactoring
> passes and one small bugfix + test additions.
Applied 0001, which looked fine and was an existing issue. At the
end, I had no issues with the names you suggested.
--
Michael
signature.asc
Description: PGP signature
