On Mon, Aug 21, 2023 at 04:44:33PM -0700, Jacob Champion wrote:
> On Mon, Aug 21, 2023 at 4:22 PM Michael Paquier wrote:
>> There are additionally two more comments in the SSL tests that could
>> be removed, I guess. Here's a v4, with Robert's latest suggestion
>> added.
>
> LGTM.
Okay. Hearin
On Mon, Aug 21, 2023 at 07:43:56PM -0400, Isaac Morland wrote:
> I hope we're not really considering removing the "trust" method. For
> testing and development purposes it's very handy — just tell the database,
> running in a VM, to allow all connections and just believe who they say
> they are fro
On Mon, Aug 21, 2023 at 4:22 PM Michael Paquier wrote:
> There are additionally two more comments in the SSL tests that could
> be removed, I guess. Here's a v4, with Robert's latest suggestion
> added.
LGTM.
> I am not sure that we need to change this historic term, TBH. Perhaps
> it would be
On Mon, 21 Aug 2023 at 19:23, Michael Paquier wrote:
I am not sure that we need to change this historic term, TBH. Perhaps
> it would be shorter to just rip off the trust method from the tree
> with a deprecation period but that's not something I'm much in favor
> off either (I use it daily for
On Mon, Aug 21, 2023 at 10:49:16AM -0700, Jacob Champion wrote:
> On Sun, Aug 20, 2023 at 4:58 PM Michael Paquier wrote:
> > Attached is a v3 to do these two things, with adjustments for two SSL
> > tests. Any objections about it?
>
> (Sorry for the long weekend delay.) No objections; you may wa
On Mon, Aug 21, 2023 at 09:27:51AM -0400, Robert Haas wrote:
> + * No authentication identity was set; this happens e.g. when the
> + * trust method is in use. For audit purposes, log a breadcrumb to
> + * explain where in the HBA this happened.
>
> Proposed rewrite: "Normally, if log_connections
On Sun, Aug 20, 2023 at 4:58 PM Michael Paquier wrote:
> Attached is a v3 to do these two things, with adjustments for two SSL
> tests. Any objections about it?
(Sorry for the long weekend delay.) No objections; you may want to
adjust the comment above the test block in t/001_password.pl, as wel
On Sun, Aug 20, 2023 at 7:58 PM Michael Paquier wrote:
> Attached is a v3 to do these two things, with adjustments for two SSL
> tests. Any objections about it?
+ * No authentication identity was set; this happens e.g. when the
+ * trust method is in use. For audit purposes, log a breadcrumb to
On Fri, Aug 18, 2023 at 08:49:16AM +0900, Michael Paquier wrote:
> 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 loggin
On Thu, Aug 17, 2023 at 03:29:28PM -0400, Stephen Frost wrote:
> On Thu, Aug 17, 2023 at 15:23 Robert Haas 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
Greetings,
On Thu, Aug 17, 2023 at 15:23 Robert Haas wrote:
> On Thu, Aug 17, 2023 at 12:54 PM Jacob Champion
> wrote:
> > On Thu, Aug 17, 2023 at 9:46 AM Stephen Frost
> wrote:
> > > Don't like 'skipped' but that feels closer.
> > >
> > > How about 'connection bypassed authentication'?
> >
>
On Thu, Aug 17, 2023 at 12:54 PM Jacob Champion wrote:
> On Thu, Aug 17, 2023 at 9:46 AM Stephen Frost 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 au
On Thu, Aug 17, 2023 at 9:46 AM Stephen Frost wrote:
> Don't like 'skipped' but that feels closer.
>
> How about 'connection bypassed authentication'?
Works for me; see v2.
Thanks!
--Jacob
From 5404c28391d2faae8a306e4e21c2ddfe1b70b53e Mon Sep 17 00:00:00 2001
From: Jacob Champion
Date: Wed, 16
Greetings,
* Jacob Champion (jchamp...@timescale.com) wrote:
> On Thu, Aug 17, 2023 at 9:01 AM Stephen Frost wrote:
> > Maybe 'connection allowed' instead..?
>
> Hm. It hasn't really been allowed yet, either. To illustrate what I mean:
>
> LOG: connection received: host=[local]
> LOG:
On Thu, Aug 17, 2023 at 9:01 AM Stephen Frost wrote:
> That doesn't seem quite right ... admittedly, 'trust' isn't performing
> authentication but there can certainly be an argument made that the
> basic 'matched a line in pg_hba.conf' is a form of authentication
I'm not personally on board with
Greetings,
* Jacob Champion (jchamp...@timescale.com) wrote:
> Maybe something like the attached?
> - 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" l
On Wed, Aug 16, 2023 at 6:27 AM Shaun Thomas
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 m
> 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 act
On Tue, Aug 15, 2023 at 03:39:10PM -0700, Jacob Champion wrote:
> 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
On Tue, Aug 15, 2023 at 3:24 PM Michael Paquier 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 aut
On Tue, Aug 15, 2023 at 04:49:47PM -0500, Shaun Thomas wrote:
> The switch statement that decodes port->hba->auth_method ends by
> simply setting status = STATUS_OK; with no supplementary output since
> it never calls set_authn_id. So in theory, a malicious user could add
> a trust line to pg_hba.c
Hi everyone,
This started as a conversation on Discord. Someone asked if Postgres
logs which line in pg_hba.conf matched against a certain login
attempt, and I said no. That's not quite right, as enabling
log_connections includes a line like this:
2023-08-15 13:26:03.159 PDT [692166] postgres@sni
22 matches
Mail list logo
