Re: Let people set host(no)ssl settings from initdb

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: David Fetter <david(at)fetter(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Let people set host(no)ssl settings from initdb
Date: 2019-12-12 09:47:52
Message-ID: 3a820006-58fd-e62a-c65f-de91d0912d42@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2019-12-12 07:24, David Fetter wrote:
>> That problem exists even before you get to the question of whether
>> this specific option is useful or well-designed ... a question I'm
>> not opining about here, but it would certainly require thought.
> I think it was a reasonable extension. We cover lines that start with
> local and host, but they can also start with hostssl and hostnossl.

I suspect the real purpose here is to easily reject non-SSL connections
altogether. This is currently quite cumbersome and requires careful
ongoing maintenance of pg_hba.conf. But I see two problems with the
proposed approach: (1) initdb doesn't support setting up SSL, so the
only thing you can achieve here is to reject all TCP/IP connections,
until you have set up SSL. (2) The default pg_hba.conf only covers
localhost connections. The value of enforcing SSL connections to
localhost is probably quite low. You still need ongoing careful
pg_hba.conf maintenance as you add more host entries.

Maybe we just need something like libpq's sslmode on the server side.
Probably not quite the same, perhaps just ssl = require.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rahila Syed 2019-12-12 09:57:53 Re: Minimal logical decoding on standbys
Previous Message Amit Kapila 2019-12-12 08:48:43 Re: logical decoding : exceeded maxAllocatedDescs for .spill files