Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue
Date
Msg-id ZN6x/OCBhRvS3KmY@paquier.xyz
Whole thread Raw
In response to Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue  (Stephen Frost <sfrost@snowman.net>)
Responses Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue
List pgsql-hackers
On Thu, Aug 17, 2023 at 03:29:28PM -0400, Stephen Frost wrote:
> On Thu, Aug 17, 2023 at 15:23 Robert Haas <robertmhaas@gmail.com> wrote:
>> For what it's worth, my vote would be for "connection authenticated:
>> ... method=trust".
>
> I don’t have any particular objection to this language and agree that it’s
> actually closer to how we talk about the trust auth method in our
> documentation.

After sleeping on it, I think that I'd just agree with Robert's point
to just use the same language as the message, while also agreeing with
the patch to not set MyClientConnectionInfo.authn_id in the uaTrust
case, only logging something under log_connections.

+        * No authentication was actually performed; this happens e.g. when the
+        * trust method is in use.

This comment should be reworded a bit, say "No authentication identity
was set; blah ..".

> Maybe if we decided to rework the documentation … or perhaps just ripped
> “trust” out entirely … but those are whole different things from what we
> are trying to accomplish here.

Not sure I see any point in doing that these days.
--
Michael

Attachment

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Normalization of utility queries in pg_stat_statements
Next
From: Michael Paquier
Date:
Subject: Re: New WAL record to detect the checkpoint redo location