pgsql: Ensure that all temp files made during pg_upgrade are non-world-

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Ensure that all temp files made during pg_upgrade are non-world-
Date: 2018-02-05 15:58:54
Message-ID: E1eijAU-0006Qw-Pp@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Ensure that all temp files made during pg_upgrade are non-world-readable.

pg_upgrade has always attempted to ensure that the transient dump files
it creates are inaccessible except to the owner. However, refactoring
in commit 76a7650c4 broke that for the file containing "pg_dumpall -g"
output; since then, that file was protected according to the process's
default umask. Since that file may contain role passwords (hopefully
encrypted, but passwords nonetheless), this is a particularly unfortunate
oversight. Prudent users of pg_upgrade on multiuser systems would
probably run it under a umask tight enough that the issue is moot, but
perhaps some users are depending only on pg_upgrade's umask changes to
protect their data.

To fix this in a future-proof way, let's just tighten the umask at
process start. There are no files pg_upgrade needs to write at a
weaker security level; and if there were, transiently relaxing the
umask around where they're created would be a safer approach.

Report and patch by Tom Lane; the idea for the fix is due to Noah Misch.
Back-patch to all supported branches.

Security: CVE-2018-1053

Branch
------
REL9_3_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/9c59e48a22aa150c4d63017955328d87bea1cd29

Modified Files
--------------
contrib/pg_upgrade/dump.c | 10 ----------
contrib/pg_upgrade/file.c | 14 --------------
contrib/pg_upgrade/pg_upgrade.c | 3 +++
contrib/pg_upgrade/pg_upgrade.h | 4 +++-
4 files changed, 6 insertions(+), 25 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Peter Eisentraut 2018-02-05 17:52:58 pgsql: Translation updates
Previous Message Tom Lane 2018-02-05 15:37:45 pgsql: Fix RelationBuildPartitionKey's processing of partition key expr