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

From Robert Haas
Subject Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue
Date
Msg-id CA+TgmobN1vi-DmEsekCFz_hzAdU8-9DihYRq4Eewnw0R+Br26Q@mail.gmail.com
Whole thread Raw
In response to Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue  (Jacob Champion <jchampion@timescale.com>)
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 12:54 PM Jacob Champion <jchampion@timescale.com> wrote:
> On Thu, Aug 17, 2023 at 9:46 AM Stephen Frost <sfrost@snowman.net> wrote:
> > Don't like 'skipped' but that feels closer.
> >
> > How about 'connection bypassed authentication'?
>
> Works for me; see v2.

For what it's worth, my vote would be for "connection authenticated:
... method=trust". The only reason we're not doing that is because
there's some argument that trusting that the client is who they say
they are is not really authentication at all. But this seems silly,
because we put "trust" in the "METHOD" column of pg_hba.conf, so in
that case we already treat it as an authentication method. Also, any
such line in pg_hba.conf still matches against the supplied IP address
mask, which I suppose could be viewed as a form of authentication. Or
maybe not. But I wonder if we're just being too persnickety about
language here, in a way that maybe isn't consistent with our previous
practice.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue
Next
From: Stephen Frost
Date:
Subject: Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue