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

From Jacob Champion
Subject Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue
Date
Msg-id CAAWbhmiP+6r0XE6pgRyD0=sRi1k4muqo-Z=eLFgLKX-6smYZmw@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  (Shaun Thomas <shaun.thomas@enterprisedb.com>)
Responses Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue
List pgsql-hackers
On Wed, Aug 16, 2023 at 6:27 AM Shaun Thomas
<shaun.thomas@enterprisedb.com> wrote:
>
> > We could do something like a LOG "connection: method=%s user=%s
> > (%s:%d)", without the "authenticated" and "identity" terms from
> > set_authn_id().  Just to drop an idea.
>
> That would be my inclination as well. Heck, just slap a log message
> right in the specific case statements that don't have actual auth as
> defined by set_authn_id. This assumes anyone really cares about it
> that much, of course. :D

Maybe something like the attached?

- I made the check more generic, rather than hardcoding it inside the
trust statement, because my OAuth proposal would add a method that
only calls set_authn_id() some of the time.
- I used the phrasing "connection not authenticated" in the hopes that
it's a bit more greppable than just "connection", especially in
combination with the existing "connection authenticated" lines.

(I'm reminded that we're reflecting an unauthenticated username as-is
into the logs, but I also don't think this makes things any worse than
they are today with the "authorized" lines.)

--Jacob

Attachment

pgsql-hackers by date:

Previous
From: Jeff Davis
Date:
Subject: Re: Faster "SET search_path"
Next
From: Andres Freund
Date:
Subject: Re: Rename ExtendedBufferWhat in 16?