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:20:25 +0000 (17:20 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 30 Sep 2010 21:20:25 +0000 (17:20 -0400)
commitb805be2587972c153dbc047dc2cc74edef92a36d
treebbe374f933f81d8ee5ce2091ff22b410198ceaae
parent1100d1eaffb26948d1080968ccaab57f698fc9d9
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
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
src/pl/plperl/plperl.c
src/pl/tcl/pltcl.c