Re: [PATCH] Reload SSL certificates on SIGHUP

On 08/26/2015 07:46 AM, Michael Paquier wrote:
> On Wed, Aug 26, 2015 at 12:24 PM, Michael Paquier
> <michael.paquier@gmail.com> wrote:
>> On Wed, Aug 26, 2015 at 10:57 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> [...]
>>> So I think the way to move this forward is to investigate how to hold
>>> the SSL config constant until SIGHUP in an EXEC_BACKEND build.  If we
>>> find out that that's unreasonably difficult, maybe we'll decide that
>>> we can live without it; but I'd like to see the question investigated
>>> rather than ignored.
>>
>> You have a point here.
>>
>> In EXEC_BACKEND, parameter updated via SIGHUP are only taken into
>> account by newly-started backends, right?
>
> Oops. I mistook with PGC_BACKEND here. Sorry for the noise.
>
>> Hence, a way to do what we
>> want is to actually copy the data needed to initialize the SSL context
>> into alternate file(s). When postmaster starts up, or when SIGHUP
>> shows up those alternate files are upserted by the postmaster.
>> be-secure-openssl.c needs also to be changed such as with EXEC_BACKEND
>> the context needs to be loaded from those alternate files. At quick
>> glance this seems doable.
>
> Still, this idea would be to use a set of alternate files in global/
> to set the context, basically something like
> config_exec_ssl_cert_file, config_exec_ssl_key_file and
> config_exec_ssl_ca_file. It does not seem to be necessary to
> manipulate [read|write]_nondefault_variables() as the use of this
> metadata should be made only when SSL context is initialized on
> backend. Other thoughts welcome.

Sorry for dropping this patch, but now I have started looking at it again.

I started implementing your suggested solution, but realized that I do
not like copying of the private key file. The private key might have
been put by the DBA on another file system for security reasons and
having PostgreSQL copy potentially sensitive data to somewhere under
pg_data seems like a surprising behavior. Especially since this only
happens on some platforms.

I guess a possible solution would be to read the files into the
postmaster (where we already have the private key today) and have
OpenSSL read the keys from memory and re-implement something like
SSL_CTX_use_certificate_chain_file() in our code, and similar things for
the other functions which now take a path. This seems like a bit too
much work to burden this patch with (and not obviously something we
would want anyway) since the behavior is already different on Windows in
the current code.

Thoughts?

I have attached a rebased version of the original patch which applies on
current master.

Andreas