Re: [BUGS] BUG #14543: libpq fails with group readable ssl keys
| От | Magnus Hagander |
|---|---|
| Тема | Re: [BUGS] BUG #14543: libpq fails with group readable ssl keys |
| Дата | |
| Msg-id | CABUevEy_2t7N2C0dM=9Fyj9+SMzpxyawpOzWpAPOtx0UX=W_vA@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [BUGS] BUG #14543: libpq fails with group readable ssl keys (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: [BUGS] BUG #14543: libpq fails with group readable ssl keys
|
| Список | pgsql-bugs |
On Tue, Feb 28, 2017 at 12:07 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
-- Bruce Momjian <bruce@momjian.us> writes:
> We changed Postgres 9.6 to allow open group permissions on the
> _server_'s SSL key if it was owned by root:
> Allow the server's <acronym>SSL</> key file to have group read
> access if it is owned by <literal>root</> (Christoph Berg)
> Is this something we should change on the client? I don't see why not,
> but the 'root' requirement would still remain.
I'm pretty suspicious of doing this on the client side. It doesn't seem
as useful, and it would open up a bunch of issues concerning e.g. what
cert authentication actually is authenticating.
It does rapidly tread into platform-specific behaviour and exactly how groups are used, yeah.
I wonder if a better choice might be to have a way to override the behavior. We're mostly trying to defend against an accidental misconfiguration after all. So perhaps we should have a way to specify something like sslkey=/foo/bar:insecure or something like that, which would ignore the permissions check on it. In this case it's very clearly a *voluntary* configuration that the user did, and therefor any analysis of the security of doing it is on them, but we retain the default behavior of clearly pointing out to a user that what they're doing might be insecure?
В списке pgsql-bugs по дате отправления: