Thread: 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.
Attachment
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-encrypted
I'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-encrypted > > I'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
Attachment
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/