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

functioncmds.c

Blame
    • Tom Lane's avatar
      ad0009e7
      Force PL and range-type support functions to be owned by a superuser. · ad0009e7
      Tom Lane authored
      We allow non-superusers to create procedural languages (with restrictions)
      and range datatypes.  Previously, the automatically-created support
      functions for these objects ended up owned by the creating user.  This
      represents a rather considerable security hazard, because the owning user
      might be able to alter a support function's definition in such a way as to
      crash the server, inject trojan-horse SQL code, or even execute arbitrary
      C code directly.  It appears that right now the only actually exploitable
      problem is the infinite-recursion bug fixed in the previous patch for
      CVE-2012-2655.  However, it's not hard to imagine that future additions of
      more ALTER FUNCTION capability might unintentionally open up new hazards.
      To forestall future problems, cause these support functions to be owned by
      the bootstrap superuser, not the user creating the parent object.
      ad0009e7
      History
      Force PL and range-type support functions to be owned by a superuser.
      Tom Lane authored
      We allow non-superusers to create procedural languages (with restrictions)
      and range datatypes.  Previously, the automatically-created support
      functions for these objects ended up owned by the creating user.  This
      represents a rather considerable security hazard, because the owning user
      might be able to alter a support function's definition in such a way as to
      crash the server, inject trojan-horse SQL code, or even execute arbitrary
      C code directly.  It appears that right now the only actually exploitable
      problem is the infinite-recursion bug fixed in the previous patch for
      CVE-2012-2655.  However, it's not hard to imagine that future additions of
      more ALTER FUNCTION capability might unintentionally open up new hazards.
      To forestall future problems, cause these support functions to be owned by
      the bootstrap superuser, not the user creating the parent object.