Use a separate interpreter for each calling SQL userid in plperl and pltcl.
authorTom Lane <tgl@sss.pgh.pa.us>
Thu, 30 Sep 2010 21:18:51 +0000 (17:18 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 30 Sep 2010 21:18:51 +0000 (17:18 -0400)
commit50595b5fce2e15b5ef26b057799b4a4cdd1c10e8
tree9dfb476ab91a15dec55c06f9c40f4335d1f32626
parent1f0eb5de9eb56a2eb71cc538f12861b084e7b03b
Use a separate interpreter for each calling SQL userid in plperl and pltcl.

There are numerous methods by which a Perl or Tcl function can subvert
the behavior of another such function executed later; for example, by
redefining standard functions or operators called by the target function.
If the target function is SECURITY DEFINER, or is called by such a
function, this means that any ordinary SQL user with Perl or Tcl language
usage rights can do essentially anything with the privileges of the target
function's owner.

To close this security hole, create a separate Perl or Tcl interpreter for
each SQL userid under which plperl or pltcl functions are executed within
a session.  However, all plperlu or pltclu functions run within a session
still share a single interpreter, since they all execute at the trust
level of a database superuser anyway.

Note: this change results in a functionality loss when libperl has been
built without the "multiplicity" option: it's no longer possible to call
plperl functions under different userids in one session, since such a
libperl can't support multiple interpreters in one process.  However, such
a libperl already failed to support concurrent use of plperl and plperlu,
so it's likely that few people use such versions with Postgres.

Security: CVE-2010-3433
12 files changed:
doc/src/sgml/installation.sgml
doc/src/sgml/plperl.sgml
doc/src/sgml/pltcl.sgml
doc/src/sgml/release-7.4.sgml
doc/src/sgml/release-8.0.sgml
doc/src/sgml/release-8.1.sgml
doc/src/sgml/release-8.2.sgml
doc/src/sgml/release-8.3.sgml
doc/src/sgml/release-8.4.sgml
doc/src/sgml/release-9.0.sgml
src/pl/plperl/plperl.c
src/pl/tcl/pltcl.c