Re: BUG #14543: libpq fails with group readable ssl keys

* Magnus Hagander (magnus(at)hagander(dot)net) wrote:
> On Tue, Feb 28, 2017 at 12:07 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> > Bruce Momjian <bruce(at)momjian(dot)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.

Agreed.

> 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?

Well, I'm not keen on forcing users to say 'insecure' when, for their
particular environment, it might be just fine. "nopermcheck" or
something would be better, imv. As long as it's clearly a user
requested behavior, I don't see any issue with it.

Thanks!

Stephen