From 751e3e6bd8c0de789d9942d925590f63ac3dd715 Mon Sep 17 00:00:00 2001 From: Andrew Dunstan Date: Mon, 13 Nov 2006 17:13:57 +0000 Subject: [PATCH] Force plperl and plperlu to run in separate interpreters. Create an error on an attempt to create the second interpreter if this is not supported by the perl installation. Per recent -hackers discussion. --- doc/src/sgml/plperl.sgml | 21 +++- doc/src/sgml/release.sgml | 34 ++++- src/pl/plperl/plperl.c | 252 ++++++++++++++++++++++++++++++++------ 3 files changed, 264 insertions(+), 43 deletions(-) diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml index b9668103ec..a94163e7be 100644 --- a/doc/src/sgml/plperl.sgml +++ b/doc/src/sgml/plperl.sgml @@ -1,4 +1,4 @@ - + PL/Perl - Perl Procedural Language @@ -646,6 +646,25 @@ $$ LANGUAGE plperl; If the above function was created by a superuser using the language plperlu, execution would succeed. + + + + For security reasons, to stop a leak of privileged operations from + PL/PerlU to PL/Perl, these two languages + have to run in separate instances of the Perl interpreter. If your + Perl installation has been appropriately compiled, this is not a problem. + However, not all installations are compiled with the requisite flags. + If PostgreSQL detects that this is the case then it will + not start a second interpreter, but instead create an error. In + consequence, in such an installation, you cannot use both + PL/PerlU and PL/Perl in the same backend + process. The remedy for this is to obtain a Perl installation created + with the appropriate flags, namely either usemultiplicity or + both usethreads and useithreads. + For more details,see the perlembed manual page. + + + diff --git a/doc/src/sgml/release.sgml b/doc/src/sgml/release.sgml index 58b4eaf50b..78a72cea00 100644 --- a/doc/src/sgml/release.sgml +++ b/doc/src/sgml/release.sgml @@ -1,4 +1,4 @@ - +