Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP
Дата
Msg-id 20170104151429.GP18360@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP  (Andreas Karlsson <andreas@proxel.se>)
Список 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 по дате отправления:

Предыдущее
От: Dilip Kumar
Дата:
Сообщение: Re: [HACKERS] UNDO and in-place update
Следующее
От: Tom Lane
Дата:
Сообщение: Re: [HACKERS] [PATCH] Reload SSL certificates on SIGHUP