pg_hba.conf.sample wording improvement
I propose the attached patch to shake up the wording in the connection
type section of pg_hba.conf.sample a bit. After the hostgssenc part was
added on, the whole thing became a bit wordy, and it's also a bit
inaccurate for example in that the current wording for "host" appears to
say that it does not apply to GSS-encrypted connections.
Attachments:
0001-pg_hba.conf.sample-Reword-connection-type-section.patchtext/plain; charset=UTF-8; name=0001-pg_hba.conf.sample-Reword-connection-type-section.patch; x-mac-creator=0; x-mac-type=0Download
From dc64f4826c4dbf3bcd1cdadb1e9f351ce45f9074 Mon Sep 17 00:00:00 2001
From: Peter Eisentraut <peter@eisentraut.org>
Date: Wed, 28 Apr 2021 07:46:48 +0200
Subject: [PATCH] pg_hba.conf.sample: Reword connection type section
---
src/backend/libpq/pg_hba.conf.sample | 13 +++++++------
1 file changed, 7 insertions(+), 6 deletions(-)
diff --git a/src/backend/libpq/pg_hba.conf.sample b/src/backend/libpq/pg_hba.conf.sample
index b6de12b298..ead092ffab 100644
--- a/src/backend/libpq/pg_hba.conf.sample
+++ b/src/backend/libpq/pg_hba.conf.sample
@@ -18,12 +18,13 @@
#
# (The uppercase items must be replaced by actual values.)
#
-# The first field is the connection type: "local" is a Unix-domain
-# socket, "host" is either a plain or SSL-encrypted TCP/IP socket,
-# "hostssl" is an SSL-encrypted TCP/IP socket, and "hostnossl" is a
-# non-SSL TCP/IP socket. Similarly, "hostgssenc" uses a
-# GSSAPI-encrypted TCP/IP socket, while "hostnogssenc" uses a
-# non-GSSAPI socket.
+# The first field is the connection type:
+# - "local" is a Unix-domain socket
+# - "host" is a TCP/IP socket (encrypted or not)
+# - "hostssl" is an SSL-encrypted TCP/IP socket
+# - "hostnossl" is a non-SSL TCP/IP socket
+# - "hostgssenc" is a GSSAPI-encrypted TCP/IP socket
+# - "hostnogssenc" is a not GSSAPI-encrypted socket
#
# DATABASE can be "all", "sameuser", "samerole", "replication", a
# database name, or a comma-separated list thereof. The "all"
--
2.31.1
On Wed, 2021-04-28 at 07:51 +0200, Peter Eisentraut wrote:
I propose the attached patch to shake up the wording in the connection
type section of pg_hba.conf.sample a bit. After the hostgssenc part was
added on, the whole thing became a bit wordy, and it's also a bit
inaccurate for example in that the current wording for "host" appears to
say that it does not apply to GSS-encrypted connections.
+1
Thanks for taking care of things like that.
Yours,
Laurenz Albe
On 2021-Apr-28, Peter Eisentraut wrote:
I propose the attached patch to shake up the wording in the connection type
section of pg_hba.conf.sample a bit. After the hostgssenc part was added
on, the whole thing became a bit wordy, and it's also a bit inaccurate for
example in that the current wording for "host" appears to say that it does
not apply to GSS-encrypted connections.
Yeah, that's a clear improvement.
Looking at it now, I wonder how well do the "hostno" options work. If I
say "hostnogssenc", is an SSL-encrypted socket good? If I say
"hostnossl", is a GSS-encrypted socket good? If so, how does that make
sense?
--
�lvaro Herrera 39�49'30"S 73�17'W
"Pensar que el espectro que vemos es ilusorio no lo despoja de espanto,
s�lo le suma el nuevo terror de la locura" (Perelandra, C.S. Lewis)
Peter Eisentraut <peter.eisentraut@enterprisedb.com> writes:
I propose the attached patch to shake up the wording in the connection
type section of pg_hba.conf.sample a bit. After the hostgssenc part was
added on, the whole thing became a bit wordy, and it's also a bit
inaccurate for example in that the current wording for "host" appears to
say that it does not apply to GSS-encrypted connections.
+1 for revising it in this general way. I notice you omitted "TCP/IP"
from the last line though:
+# - "hostnogssenc" is a not GSSAPI-encrypted socket
which doesn't seem consistent.
Another thought is to switch the phrase order:
+# - "local" is a Unix-domain socket
+# - "host" is a TCP/IP socket (encrypted or not)
+# - "hostssl" is a TCP/IP socket that is SSL-encrypted
+# - "hostnossl" is a TCP/IP socket that is not SSL-encrypted
+# - "hostgssenc" is a TCP/IP socket that is GSSAPI-encrypted
+# - "hostnogssenc" is a TCP/IP socket that is not GSSAPI-encryptedI'm not wedded to that idea, but it seems to help reduce random
variations between the wordings of these lines.
regards, tom lane
Alvaro Herrera <alvherre@alvh.no-ip.org> writes:
Looking at it now, I wonder how well do the "hostno" options work. If I
say "hostnogssenc", is an SSL-encrypted socket good? If I say
"hostnossl", is a GSS-encrypted socket good? If so, how does that make
sense?
Kind of off-topic for this thread, but I wonder if we should introduce
"hostenc" and "hostnoenc" to mean "encrypted (or not), and I don't care
by which method". The addition of GSS has made it painful to express
those concepts.
regards, tom lane
On 28.04.21 16:20, Tom Lane wrote:
Another thought is to switch the phrase order:
+# - "local" is a Unix-domain socket +# - "host" is a TCP/IP socket (encrypted or not) +# - "hostssl" is a TCP/IP socket that is SSL-encrypted +# - "hostnossl" is a TCP/IP socket that is not SSL-encrypted +# - "hostgssenc" is a TCP/IP socket that is GSSAPI-encrypted +# - "hostnogssenc" is a TCP/IP socket that is not GSSAPI-encryptedI'm not wedded to that idea, but it seems to help reduce random
variations between the wordings of these lines.
done that way
On 28.04.21 16:09, Alvaro Herrera wrote:
Looking at it now, I wonder how well do the "hostno" options work. If I
say "hostnogssenc", is an SSL-encrypted socket good? If I say
"hostnossl", is a GSS-encrypted socket good? If so, how does that make
sense?
I think for example if you want to enforce SSL connections, then writing
"hostnossl ... reject" would be sensible. That would also reject
GSS-encrypted connections, but that would be what you want in that scenario.
On Thu, Apr 29, 2021 at 7:08 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:
On 28.04.21 16:09, Alvaro Herrera wrote:
Looking at it now, I wonder how well do the "hostno" options work. If I
say "hostnogssenc", is an SSL-encrypted socket good? If I say
"hostnossl", is a GSS-encrypted socket good? If so, how does that make
sense?I think for example if you want to enforce SSL connections, then writing
"hostnossl ... reject" would be sensible. That would also reject
GSS-encrypted connections, but that would be what you want in that scenario.
I'd say the interface has become a lot less well-matching now that we
have two separate settings for it. For example right now it's more
complex to say "reject anything not encrypted", which I bet is what a
lot of people would want. They don't particularly care if it's gss
encrypted or ssl encrypted.
Perhaps what we want to do (obviously not for 14) is to allow you to
specify more than one entry in the first column, so you could say
"hostssl,hostgssenc" on the same row? That would give some strange
results with the "no" mappings, but it might work if used right?
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/
Greetings,
* Magnus Hagander (magnus@hagander.net) wrote:
On Thu, Apr 29, 2021 at 7:08 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:On 28.04.21 16:09, Alvaro Herrera wrote:
Looking at it now, I wonder how well do the "hostno" options work. If I
say "hostnogssenc", is an SSL-encrypted socket good? If I say
"hostnossl", is a GSS-encrypted socket good? If so, how does that make
sense?I think for example if you want to enforce SSL connections, then writing
"hostnossl ... reject" would be sensible. That would also reject
GSS-encrypted connections, but that would be what you want in that scenario.I'd say the interface has become a lot less well-matching now that we
have two separate settings for it. For example right now it's more
complex to say "reject anything not encrypted", which I bet is what a
lot of people would want. They don't particularly care if it's gss
encrypted or ssl encrypted.
I'm not really sure that I agree it's such an issue, particularly since
you have to come up with a way to specify the auth method to use somehow
too as we haven't got any fallback mechanism or anything like that.
While you might use cert-based auth or SCRAM for TLS connections, it
isn't the case that you can use SCRAM with a GSS encrypted connection.
Perhaps what we want to do (obviously not for 14) is to allow you to
specify more than one entry in the first column, so you could say
"hostssl,hostgssenc" on the same row? That would give some strange
results with the "no" mappings, but it might work if used right?
In general, I'm not against the idea of giving more options but I'm just
not sure that it's a real use-case when you consider that the auth
method also has to be specified. I also don't recall anyone showing up
asking about how they could specify "encrypted but I don't care how".
Thanks,
Stephen
On Wed, Apr 28, 2021 at 07:51:43AM +0200, Peter Eisentraut wrote:
I propose the attached patch to shake up the wording in the connection type
section of pg_hba.conf.sample a bit. After the hostgssenc part was added
on, the whole thing became a bit wordy, and it's also a bit inaccurate for
example in that the current wording for "host" appears to say that it does
not apply to GSS-encrypted connections.
Yes, much better.
--
Bruce Momjian <bruce@momjian.us> https://momjian.us
EDB https://enterprisedb.com
If only the physical world exists, free will is an illusion.
On Thu, Apr 29, 2021 at 5:06 PM Stephen Frost <sfrost@snowman.net> wrote:
Greetings,
* Magnus Hagander (magnus@hagander.net) wrote:
On Thu, Apr 29, 2021 at 7:08 AM Peter Eisentraut
<peter.eisentraut@enterprisedb.com> wrote:On 28.04.21 16:09, Alvaro Herrera wrote:
Looking at it now, I wonder how well do the "hostno" options work. If I
say "hostnogssenc", is an SSL-encrypted socket good? If I say
"hostnossl", is a GSS-encrypted socket good? If so, how does that make
sense?I think for example if you want to enforce SSL connections, then writing
"hostnossl ... reject" would be sensible. That would also reject
GSS-encrypted connections, but that would be what you want in that scenario.I'd say the interface has become a lot less well-matching now that we
have two separate settings for it. For example right now it's more
complex to say "reject anything not encrypted", which I bet is what a
lot of people would want. They don't particularly care if it's gss
encrypted or ssl encrypted.I'm not really sure that I agree it's such an issue, particularly since
you have to come up with a way to specify the auth method to use somehow
too as we haven't got any fallback mechanism or anything like that.
While you might use cert-based auth or SCRAM for TLS connections, it
isn't the case that you can use SCRAM with a GSS encrypted connection.Perhaps what we want to do (obviously not for 14) is to allow you to
specify more than one entry in the first column, so you could say
"hostssl,hostgssenc" on the same row? That would give some strange
results with the "no" mappings, but it might work if used right?In general, I'm not against the idea of giving more options but I'm just
not sure that it's a real use-case when you consider that the auth
method also has to be specified. I also don't recall anyone showing up
asking about how they could specify "encrypted but I don't care how".
TBH, I bet that is a lot because people don't use gss encryption, or
even know it exists. Which is sad, because it's darn convenient once
you have Kerberos set up...
--
Magnus Hagander
Me: https://www.hagander.net/
Work: https://www.redpill-linpro.com/