summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
authorAndrew Dunstan2010-05-13 16:44:35 +0000
committerAndrew Dunstan2010-05-13 16:44:35 +0000
commit60028fda9f1009fdc76b6d011b1830b99ae6422c (patch)
treee8685b155a018ada2423cd9621ff75fc012abee5 /doc
parente2740649a03c3a672177f6c84a84e49011c45068 (diff)
Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is
fundamentally insecure. Instead apply an opmask to the whole interpreter that imposes restrictions on unsafe operations. These restrictions are much harder to subvert than is Safe.pm, since there is no container to be broken out of. Backported to release 7.4. In releases 7.4, 8.0 and 8.1 this also includes the necessary backporting of the two interpreters model for plperl and plperlu adopted in release 8.2. In versions 8.0 and up, the use of Perl's POSIX module to undo its locale mangling on Windows has become insecure with these changes, so it is replaced by our own routine, which is also faster. Nice side effects of the changes include that it is now possible to use perl's "strict" pragma in a natural way in plperl, and that perl's $a and $b variables now work as expected in sort routines, and that function compilation is significantly faster. Tim Bunce and Andrew Dunstan, with reviews from Alex Hunsaker and Alexey Klyukin. Security: CVE-2010-1169
Diffstat (limited to 'doc')
-rw-r--r--doc/src/sgml/plperl.sgml23
1 files changed, 21 insertions, 2 deletions
diff --git a/doc/src/sgml/plperl.sgml b/doc/src/sgml/plperl.sgml
index 8e834b08197..aa3838698d8 100644
--- a/doc/src/sgml/plperl.sgml
+++ b/doc/src/sgml/plperl.sgml
@@ -1,5 +1,5 @@
<!--
-$Header: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v 2.20 2003/08/31 17:32:19 petere Exp $
+$Header: /cvsroot/pgsql/doc/src/sgml/plperl.sgml,v 2.20.2.1 2010/05/13 16:44:35 adunstan Exp $
-->
<chapter id="plperl">
@@ -259,7 +259,26 @@ CREATE FUNCTION badfunc() RETURNS integer AS '
If the above function was created by a superuser using the language
<literal>plperlu</>, execution would succeed.
</para>
- </sect1>
+
+ <note>
+ <para>
+ For security reasons, to stop a leak of privileged operations from
+ <application>PL/PerlU</> to <application>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 <productname>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
+ <application>PL/PerlU</> and <application>PL/Perl</> in the same backend
+ process. The remedy for this is to obtain a Perl installation created
+ with the appropriate flags, namely either <literal>usemultiplicity</> or
+ both <literal>usethreads</> and <literal>useithreads</>.
+ For more details,see the <literal>perlembed</> manual page.
+ </para>
+ </note>
+
+</sect1>
<sect1 id="plperl-missing">
<title>Missing Features</title>