Re: Relaxing SSL key permission checks

From: Christoph Berg <myon(at)debian(dot)org>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Relaxing SSL key permission checks
Date: 2016-03-05 20:06:56
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

Re: Alvaro Herrera 2016-03-04 <20160304205521(dot)GA735336(at)alvherre(dot)pgsql>
> For the sake of cleanliness, I propose splitting out the checks for
> regular file and for owned-by-root-or-us from the actual chmod-level
> checks at the same time. That way we can provide more specific error
> messages for each case. (Furthermore, I'm pretty sure that the check
> for superuserness could be applied on Windows also -- in the attached
> patch it's still #ifdef'ed out, because I don't know how to write it.)

Thanks, this is a reasonable improvement. I've included your patch in
the 9.6 Debian package and also implemented some regression tests in
postgresql-common to make sure the bad permissions are indeed catched.

> After doing that change I started to look at the details of the check
> and found some mistakes:
> * it said "g=w" instead of "g=r", in contradiction with the numeric
> specification: g=w means 020 rather than 040. We want the file to be
> group-readable, not group-writeable.

Typo on my side, sorry.

> * it failed to check for S_IXUSR, so permissions 0700 were okay, in
> contradiction with what the error message indicates. This is a
> preexisting bug actually. Do we want to fix it by preventing a
> user-executable file (possibly breaking compability with existing
> executable key files), or do we want to document what the restriction
> really is?

x on regular files doesn't do anything, so it wouldn't matter, but of
course syncing the code with the error message makes sense. I don't
think 0700 is a case that is seen in the wild (in contrast to 0777
files), and even if so, the error message clearly says what the
problem is.

cb(at)df7cb(dot)de |

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Joe Conway 2016-03-05 20:49:33 Re: Proposal: SET ROLE hook
Previous Message Tom Lane 2016-03-05 20:02:50 Re: WIP: Upper planner pathification