Re: re-reading SSL certificates during server reload
От | Andres Freund |
---|---|
Тема | Re: re-reading SSL certificates during server reload |
Дата | |
Msg-id | 20140828142654.GE25984@awork2.anarazel.de обсуждение исходный текст |
Ответ на | Re: re-reading SSL certificates during server reload (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: re-reading SSL certificates during server reload
|
Список | pgsql-hackers |
On 2014-08-28 10:20:08 -0400, Tom Lane wrote: > Andres Freund <andres@2ndquadrant.com> writes: > > On 2014-08-28 10:12:19 -0400, Tom Lane wrote: > >> Hm. Yeah, I guess there is some use in holding onto the values that were > >> actually used to initialize the current session, or at least there would > >> be if we exposed the cert contents in any fashion. > > > Won't that allow the option to be specified at connection start by mere > > mortal users? That sounds odd to me. > > Well, no, because SSL would be established (or not) before we ever process > the contents of the connection request packet. You might be able to > change the value that SHOW reports, but not the value actually governing > your session. Sure. There's probably nothing happening with ssl 'that late' right now. But and it seems like a invitation for trouble later to me. Even if it's just that other code copies the logic, thinking it'd also be safe. > Having said that, there's a nearby thread about inventing a "SUBACKEND" > GUC category, and that's likely what we'd really want to use here, just > on the grounds that superusers would know better. What we really want is PGC_SIGHUP | PGC_BACKEND, right? I wonder if it's not better to allow for some cominations of GucContext's by bitmask, instead of adding SUBACKEND and HUPBACKEND and whatever else might make sense. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/PostgreSQL Development, 24x7 Support, Training & Services
В списке pgsql-hackers по дате отправления: