pg_ident.conf + regular expressions issue

Alexey Shishkin <alexey.shishkin.01@gmail.com> writes:

Pls. find attached the results of my tests regarding the topic.
I'm not 100% sure it's a bug, but at least it doesn't work as expected.

There is something wrong with your test procedure. For example,
in test05 the log message clearly shows that peer authentication
failed, although you claimed to be testing ident authentication.
You haven't given enough detail to determine why that happened;
perhaps failure to do "pg_ctl reload" after changing config files?

One point worth noting is that ident auth only works on TCP
connections, not connections via a Unix socket.

regards, tom lane

On Monday, October 21, 2024, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Alexey Shishkin <alexey.shishkin.01@gmail.com> writes:

Pls. find attached the results of my tests regarding the topic.
I'm not 100% sure it's a bug, but at least it doesn't work as expected.

There is something wrong with your test procedure. For example,
in test05 the log message clearly shows that peer authentication
failed, although you claimed to be testing ident authentication.

The OP never said they were using the ident auth-method. The test involves
peer authentication with a user name mapping file, pg_ident.conf. Not
specifically the ident authentication type (which devolves to peer anyway
if the connection is local).

The test seems like it needs some heavy simplification but at a glance it
seems to have the necessary elements buried in it somewhere.

David J.

On Mon, Oct 21, 2024 at 4:33 AM Alexey Shishkin <
alexey.shishkin.01@gmail.com> wrote:

I'm not 100% sure it's a bug, but at least it doesn't work as expected.

You seem to be expecting regular expressions to be able to turn what is a
case-sensitive login matching process into a case-insensitive one. A
regular expression cannot do that - well, not one that uses \1.

The value of \1 is going to be in whatever case the OS user name is. So if
you try and login with a case that doesn't match the case of the role
supplied with -U the login attempt will fail. If they do match, it will
succeed. You have to get rid of the \1 and hardcode "smokeybear" as the PG
user name if you want any random capitalization of smokeybear to be able to
login using that role name (not tested...).

David J.

"David G. Johnston" <david.g.johnston@gmail.com> writes:

The OP never said they were using the ident auth-method. The test involves
peer authentication with a user name mapping file, pg_ident.conf. Not
specifically the ident authentication type (which devolves to peer anyway
if the connection is local).

Ah, right, -ENOCAFFEINE: I'd forgotten that "ident" is automatically
converted to "peer" for a Unix-socket connection. So that explains
the phrasing of the error message.

Given that, I don't see anything wrong with the behavior of test05.
The OS user name SMOKEYBEAR successfully matches the rule, sure,
and then the \1 says that that user can log in as role SMOKEYBEAR.
But the request is to log in as smokeybear (lower case), so it fails.
The "(?i)" option only makes the regex able to match different casings
of the OS name, it doesn't make matching of the \1 result to the
requested role name be case-insensitive.

test11 seems to be the same thing, only with actual ident auth.

regards, tom lane

Dear all,

Thank you for your prompt reply !

Some clarifications regarding the tests:
- I did "pg_ctl reload" after changing config files
- test01-test06 are really about 'peer' authentication instead of 'ident'
authentication
- so, lets concentrate on test07-test12

Let me rephrase my question about regular expressions + pg_ident.conf:
- why test09 is successful, while test10 fails ?

best regards,
Alexey Shishkin
alexey.shishkin.01@gmail.com

On Mon, Oct 21, 2024 at 5:49 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Alexey Shishkin <alexey.shishkin.01@gmail.com> writes:

Let me rephrase my question about regular expressions + pg_ident.conf:
- why test09 is successful, while test10 fails ?

I don't see why that one surprises you. "/(?c)^(.*SMOKEYBEAR)$" does
not match "smokeybear".

regards, tom lane

OK, what we have is:

"(?c)^(.*SMOKEYBEAR)$" does not match "smokeybear"

and at the same time:

"(?i)^(.*SMOKEYBEAR)$" does match "smokeybear"

How the latter is possible ?

best regards,
Alexey Shishkin
alexey.shishkin.01@gmail.com

On Mon, Oct 21, 2024 at 9:39 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:

Alexey Shishkin <alexey.shishkin.01@gmail.com> writes:

OK, what we have is:
"(?c)^(.*SMOKEYBEAR)$" does not match "smokeybear"
and at the same time:
"(?i)^(.*SMOKEYBEAR)$" does match "smokeybear"
How the latter is possible ?

Uh, that's the entire point of the "i" flag, no?
See about embedded options here:

https://www.postgresql.org/docs/current/functions-matching.html#POSIX-METASYNTAX

regards, tom lane

On Monday, October 21, 2024, Alexey Shishkin <alexey.shishkin.01@gmail.com>
wrote:

OK, what we have is:

"(?c)^(.*SMOKEYBEAR)$" does not match "smokeybear"

and at the same time:

"(?i)^(.*SMOKEYBEAR)$" does match "smokeybear"

How the latter is possible ?

I suggest you explain in your own words what those two regular expressions
are attempting to do. Why do you expect the second one to not match? Why
does the first one not match?

David J.