Re: [PATCH] Reload SSL certificates on SIGHUP - Mailing list pgsql-hackers

From Michael Paquier
Subject Re: [PATCH] Reload SSL certificates on SIGHUP
Date
Msg-id CAB7nPqQkLj1rbjv5_MiER0-Snmpv2nQDEXMiO1QFY3==noCk1A@mail.gmail.com
Whole thread Raw
In response to Re: [PATCH] Reload SSL certificates on SIGHUP  (Andreas Karlsson <andreas@proxel.se>)
Responses Re: [PATCH] Reload SSL certificates on SIGHUP  (Victor Wagner <vitus@wagner.pp.ru>)
Re: [PATCH] Reload SSL certificates on SIGHUP  (Andreas Karlsson <andreas@proxel.se>)
List pgsql-hackers
On Sun, Sep 4, 2016 at 11:39 PM, Andreas Karlsson <andreas@proxel.se> wrote:
> 1) Serialize the certificates, key, and CRL and write them to the
> backend_var temp file and then deserialize everything in the backends.
>
> Sounds like you would need to write some code for every SSL library to
> support the serialization and deserialization, which I am not a fan of doing
> just for one platform since I worry about little used code paths.
> Additionally this would mean that we write a copy of the private key to
> potentially another file system than the one where the private key is
> stored, this sounds like a bad idea from a security point of view.

Yeah... This would result in something that is heavily SSL-dependent,
which would be an additional maintenance pain when trying to support
future OpenSSL versions.

> 2) Copy all the SSL related files into the data directory at SIGHUP, before
> loading them. While this does not require any serialization of certificates
> it still has the problem of writing private keys to disk.

You expressed enough concern about that upthread, copying private keys
into PGDATA is a security concern.

> 3) Leave my patch as it is now. This means the postmaster will reload
> certificates on SIGHUP while the backends will also load them when spawning.
> This means windows will continue to work the same as before my patch.
>
> Is there any other way to pass the current set of loaded certificates and
> keys from the postmaster to the backends on Windows? I guess you could use a
> pipe, but if so we should probably send all data on this pipe, not just the
> SSL stuff.
>
> I am leaning towards doing (3) but I know I am biased since it is less work
> and I do not care much for Windows.

Seriously... The benefit of this feature is clear for a lot of people.
And the implementation dedicated only to Windows would just result in
a grotty thing anyway. So I'd say that at this point we could just
push for 3) and facilitate the life of most with SSL configuration.
The behavior across platforms needs to be properly documented for
sure.
-- 
Michael



pgsql-hackers by date:

Previous
From: Stas Kelvich
Date:
Subject: Re: Speedup twophase transactions
Next
From: Rajkumar Raghuwanshi
Date:
Subject: Re: Declarative partitioning - another take