Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

pg_upgrade.c

Blame
    • Tom Lane's avatar
      17aa0236
      Ensure that all temp files made during pg_upgrade are non-world-readable. · 17aa0236
      Tom Lane authored
      pg_upgrade has always attempted to ensure that the transient dump files
      it creates are inaccessible except to the owner.  However, refactoring
      in commit 76a7650c 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
      17aa0236
      History
      Ensure that all temp files made during pg_upgrade are non-world-readable.
      Tom Lane authored
      pg_upgrade has always attempted to ensure that the transient dump files
      it creates are inaccessible except to the owner.  However, refactoring
      in commit 76a7650c 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