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

On Wed, Dec 30, 2020 at 03:00:17PM -0500, Tom Lane wrote:
> David Fetter <david(at)fetter(dot)org> writes:
> > On Wed, Dec 30, 2020 at 08:24:06PM +0100, David Fetter wrote:
> >> On Mon, Sep 07, 2020 at 11:57:58AM +0900, Michael Paquier wrote:
> >>> I have looked at the patch of this thread, and I doubt that it is a
> >>> good idea to put more burden into initdb for that. I agree that
> >>> being able to reject easily non-SSL connections in pg_hba.conf is a
> >>> bit of a hassle now, but putting more logic into initdb does not seem
> >>> the right course to me. Perhaps we could consider an idea like
> >>> Peter's to have a sslmode=require on the server side and ease the
> >>> generation of HBA rules..
>
> >> Please find attached the rebased patch.
> >>
> >> Peter's suggestion seems a little more subtle to me than requiring TLS
> >> on the server side in that what people generally want to do is
> >> disallow clear text connections entirely. In those scenarios, people
> >> would also want to set (and be able to change at runtime) some kind of
> >> cryptographic policy, as SSH and TLS do. While I see this as a worthy
> >> goal, it's a much bigger lift than an optional argument or two to
> >> initdb, and requires a lot more discussion than it's had to date.
>
> FWIW, I still agree with what Michael says above. I do not think
> that adding more options to initdb is a useful solution here.
> In the first place, it's unlikely that we'll manage to cover many
> people's exact requirements this way. In the second place, it's
> very unclear where to stop adding options. In the third place,
> I believe the vast majority of users don't invoke initdb "by hand"
> anymore. The typical scenario is to go through a packager-provided
> script, which almost certainly won't offer access to these additional
> options. In the fourth place, many people won't know at initdb time
> exactly what they should do, or they'll change their minds later.

To that last, I suspect that there are folks in regulated industries
who want to be able to show that they've deployed at some kind of
minimal level of protection. If there's not a window during which a
non-conforming pg_hba.conf is in play, that's easier to do.

> The last two points suggest that what'd be more useful is some sort
> of tool to modify an existing pg_hba.conf file. Or maybe even just
> audit a file to see if it implements $desired-policy, such as
> "no unencrypted network connections" or "no plaintext passwords".
> (I kind of like the auditing-tool approach; it seems less scary
> than something that actually rewrites the file.)

Am I understanding correctly that you're suggesting we write up a
formal specification of pg_hba.conf? That could be handy if we don't
choose to export the parser the backend uses for it, for example
because we want it to respond super quickly to HUPs, which might
conflict with making it usable by things that weren't the backend.

I agree that anything that does a write to pg_hba.conf needs to be
approached with a good deal of caution. Audit tools such as you
propose could spit out a suggestion that doesn't overwrite, although
it could get a little hairy if it's intended to patch something that
has an include directive in it.

Best,
David.
--
David Fetter <david(at)fetter(dot)org> http://fetter.org/
Phone: +1 415 235 3778

Remember to vote!
Consider donating to Postgres: http://www.postgresql.org/about/donate