Re: unclear wording re: spoofing prevention on network connections

From: "David G(dot) Johnston" <david(dot)g(dot)johnston(at)gmail(dot)com>
To: Stephen Frost <sfrost(at)snowman(dot)net>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, "edgecase14(at)gmail(dot)com" <edgecase14(at)gmail(dot)com>, "pgsql-docs(at)lists(dot)postgresql(dot)org" <pgsql-docs(at)lists(dot)postgresql(dot)org>
Subject: Re: unclear wording re: spoofing prevention on network connections
Date: 2023-12-09 17:01:43
Message-ID: CAKFQuwZn8szK6L_EJpQm2UawCm+-b3S6T-gYdfuP79CU3bzxVA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs

On Saturday, December 9, 2023, Stephen Frost <sfrost(at)snowman(dot)net> wrote:

>
>
> The idea is that you can use both TLS and GSSAPI-with-encryption at the
> same time within a given cluster for connections but you wouldn’t use them
> on the same connection. Certainly would welcome suggestions as to the best
> way to phrase that.
>

It isn’t really connection driven though - or even specific to these two
options. The pg_hba.conf file can contain any number of different
authentication methods that are usable simultaneously (from the perspective
of the cluster). But a given login request is only going to match a single
one of those lines; so it isn’t like the client somehow decides during each
login using the same machine and user name which way they are going to
verify who they say they are.

We don’t call out being able to use password and peer simultaneously, the
description and specification of the pg_hba.conf file itself imparts that
information. I’m unclear why these two would warrant a special calling out.

David J.

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Stephen Frost 2023-12-09 17:38:43 Re: unclear wording re: spoofing prevention on network connections
Previous Message Stephen Frost 2023-12-09 16:52:52 Re: unclear wording re: spoofing prevention on network connections