Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue

From: Jacob Champion <jchampion(at)timescale(dot)com>
To: Michael Paquier <michael(at)paquier(dot)xyz>
Cc: Shaun Thomas <shaun(dot)thomas(at)enterprisedb(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Logging of matching pg_hba.conf entry during auth skips trust auth, potential security issue
Date: 2023-08-15 22:39:10
Message-ID: CAAWbhmiyvLd+srD+tXsE6JEbzYSr72tt21X_01XmGcA9p5mg2A@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 15, 2023 at 3:24 PM Michael Paquier <michael(at)paquier(dot)xyz> wrote:
> The first message from Jacob outlines the idea behind the handling of
> trust. We could perhaps add one extra set_authn_id() for the uaTrust
> case (not uaCert!) if that's more helpful.

I'm not super comfortable with saying "connection authenticated" when
it explicitly hasn't been (nor with switching the meaning of a
non-NULL SYSTEM_USER from "definitely authenticated somehow" to "who
knows; parse it apart to see"). But adding a log entry ("connection
trusted:" or some such?) with the pointer to the HBA line that made it
happen seems like a useful audit helper to me.

--Jacob

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2023-08-15 22:39:20 Re: Would it be possible to backpatch Close support in libpq (28b5726) to PG16?
Previous Message Michael Paquier 2023-08-15 22:36:07 Re: Would it be possible to backpatch Close support in libpq (28b5726) to PG16?