Thread

Commits

  1. pg_hba.conf.sample: Reword connection type section

  1. pg_hba.conf.sample wording improvement

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2021-04-28T05:51:43Z

    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.
    
  2. Re: pg_hba.conf.sample wording improvement

    Laurenz Albe <laurenz.albe@cybertec.at> — 2021-04-28T06:54:51Z

    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
    
    
    
    
    
  3. Re: pg_hba.conf.sample wording improvement

    Alvaro Herrera <alvherre@alvh.no-ip.org> — 2021-04-28T14:09:46Z

    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)
    
    
    
    
  4. Re: pg_hba.conf.sample wording improvement

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-04-28T14:20:14Z

    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
    
    
    
    
  5. Re: pg_hba.conf.sample wording improvement

    Tom Lane <tgl@sss.pgh.pa.us> — 2021-04-28T14:30:27Z

    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
    
    
    
    
  6. Re: pg_hba.conf.sample wording improvement

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2021-04-29T05:06:05Z

    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
    
    
    
    
  7. Re: pg_hba.conf.sample wording improvement

    Peter Eisentraut <peter.eisentraut@enterprisedb.com> — 2021-04-29T05:07:54Z

    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.
    
    
    
    
    
  8. Re: pg_hba.conf.sample wording improvement

    Magnus Hagander <magnus@hagander.net> — 2021-04-29T09:47:08Z

    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/
    
    
    
    
  9. Re: pg_hba.conf.sample wording improvement

    Stephen Frost <sfrost@snowman.net> — 2021-04-29T15:06:18Z

    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
    
  10. Re: pg_hba.conf.sample wording improvement

    Bruce Momjian <bruce@momjian.us> — 2021-04-30T14:29:44Z

    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.
    
    
    
    
    
  11. Re: pg_hba.conf.sample wording improvement

    Magnus Hagander <magnus@hagander.net> — 2021-05-17T20:10:39Z

    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/