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

From Stephen Frost
Subject Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP
Date
Msg-id 20170104151429.GP18360@tamriel.snowman.net
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP  (Andreas Karlsson <andreas@proxel.se>)
List pgsql-hackers
* Andreas Karlsson (andreas@proxel.se) wrote:
> On 01/04/2017 03:48 PM, Magnus Hagander wrote:
> >On Wed, Jan 4, 2017 at 3:47 PM, Tom Lane <tgl@sss.pgh.pa.us
> >    It does not; what would be the point, if the key would be lost at
> >    SIGHUP?
> >
> >If we lost it, yes. But we could keep the old key around if it hasn't
> >changed, thus behave just like we did in <= 9.6.
>
> That means storing the pass phrase in the memory of the postmaster,
> which does not sound like a terribly good idea to me, but I have
> never used keys with pass phrases for daemons so it might be a
> common solution which is acceptable by many.

I'm not sure I see that as a big deal- if you can access the
postmaster's memory then you can just pull out the actual private key
itself, no?  There's a bigger issue here though, which has to do with
what happens if the user actually does change the passphrase on the key
and we then reload, what do we do then?

> >    If any of those number of people want to step up and design/implement
> >    a non-broken solution for passphrases, that'd be fine with me.  But
> >    I would want to see something that's actually a credible solution,
> >    allowing the postmaster to be started as a normal daemon.  And working
> >    on Windows.
> >
> >Well, for all those people 9.6 worked significantly better... Because
> >they could reload *other* config parameters without failure.
>
> A possible solution might be to only add the error throwing hook
> when loading certificates during SIGHUP (and at Windows) and to work
> as before on startup. Would that be an acceptable solution? I could
> write a patch for this if people are interested.

I'm not sure I see how that's a solution..?  Wouldn't that mean that a
SIGHUP with an encrypted key would result in a failure?

The solution, at least in my view, seems to be to say "sorry, we can't
reload the SSL stuff if you used a passphrase to unlock the key on
startup, you will have to perform a restart if you want the SSL bits to
be changed."

No, I've not looked at what that would require in terms of code.

Thanks!

Stephen

pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] UNDO and in-place update
Next
From: Tom Lane
Date:
Subject: Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP