]> granicus.if.org Git - postgresql/commit
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:21:59 +0000 (17:21 -0400)
committerTom Lane <tgl@sss.pgh.pa.us>
Thu, 30 Sep 2010 21:21:59 +0000 (17:21 -0400)
commit329d7554a6406e382ef7fe7940dd1b131540a00b
treea19de9f16a5085c90b09f16c7a97b60c2b134fe0
parent51b69efc28948fbba0d6e28cbc6327b02c3ec341
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
src/pl/plperl/plperl.c
src/pl/tcl/pltcl.c