Re: Let people set host(no)ssl settings from initdb - Mailing list pgsql-hackers
| From | Magnus Hagander |
|---|---|
| Subject | Re: Let people set host(no)ssl settings from initdb |
| Date | |
| Msg-id | CABUevExG5xe=+DOz5RdYD30_wWDDj4ohryC03JghAqo8aCsmog@mail.gmail.com Whole thread Raw |
| In response to | Re: Let people set host(no)ssl settings from initdb (Tom Lane <tgl@sss.pgh.pa.us>) |
| List | pgsql-hackers |
On Wed, Dec 30, 2020 at 9:00 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
David Fetter <david@fetter.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.
AFAIK bot the debian/ubuntu script mentioned by Isaac downthread, and the RedHat/Fedora ones do allow you to specify inidb options. That would cover the majority I'd say...
That said, I agree with not adding it as an option to initdb. You'll quickly get to the point where you specify the whole pg_hba file on the commandline to initdb -- and most people today who actually care that much about it would have their pg_hba.conf file under some sort of configuration management anyway, whether it's ansible, chef, puppet or something else.
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
I don't think we need, or indeed want, a tool to *modify* pg_hba.conf. For people who want that, there are already plenty options out there in the configuration management space, let's not invent our own.
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.)
Audiring, however, is a lot more interesting.
For people who actually care about most of this, it's not that important what the initial one is, if it can trivially be changed to become insecure. And unfortunately due to the complexity of pg_hba, that can easily happen. Keeping it under configuration management helps with that, but doesn't entirely solve the problem.
Another possible approach could be to add global gucs for "allow_unencrypted_connections" and maybe "available_authentication_methods". That would override pg_hba. At least in doing so, there would be *one* spot where one could fairly strictly lock things down. (Similar to Peters suggestion upthread)
pgsql-hackers by date: