<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<HTML
><HEAD
><TITLE
>Trusted and Untrusted PL/Perl</TITLE
><META
NAME="GENERATOR"
CONTENT="Modular DocBook HTML Stylesheet Version 1.79"><LINK
REV="MADE"
HREF="mailto:pgsql-docs@postgresql.org"><LINK
REL="HOME"
TITLE="PostgreSQL 8.3.6 Documentation"
HREF="index.html"><LINK
REL="UP"
TITLE="PL/Perl - Perl Procedural Language"
HREF="plperl.html"><LINK
REL="PREVIOUS"
TITLE="Global Values in PL/Perl"
HREF="plperl-global.html"><LINK
REL="NEXT"
TITLE="PL/Perl Triggers"
HREF="plperl-triggers.html"><LINK
REL="STYLESHEET"
TYPE="text/css"
HREF="stylesheet.css"><META
HTTP-EQUIV="Content-Type"
CONTENT="text/html; charset=ISO-8859-1"><META
NAME="creation"
CONTENT="2009-02-03T04:34:16"></HEAD
><BODY
CLASS="SECT1"
><DIV
CLASS="NAVHEADER"
><TABLE
SUMMARY="Header navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TH
COLSPAN="5"
ALIGN="center"
VALIGN="bottom"
>PostgreSQL 8.3.6 Documentation</TH
></TR
><TR
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="plperl-global.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="10%"
ALIGN="left"
VALIGN="top"
><A
HREF="plperl.html"
>Fast Backward</A
></TD
><TD
WIDTH="60%"
ALIGN="center"
VALIGN="bottom"
>Chapter 40. PL/Perl - Perl Procedural Language</TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="plperl.html"
>Fast Forward</A
></TD
><TD
WIDTH="10%"
ALIGN="right"
VALIGN="top"
><A
HREF="plperl-triggers.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
></TABLE
><HR
ALIGN="LEFT"
WIDTH="100%"></DIV
><DIV
CLASS="SECT1"
><H1
CLASS="SECT1"
><A
NAME="PLPERL-TRUSTED"
>40.5. Trusted and Untrusted PL/Perl</A
></H1
><A
NAME="AEN45646"
></A
><P
> Normally, PL/Perl is installed as a <SPAN
CLASS="QUOTE"
>"trusted"</SPAN
> programming
language named <TT
CLASS="LITERAL"
>plperl</TT
>. In this setup, certain Perl
operations are disabled to preserve security. In general, the
operations that are restricted are those that interact with the
environment. This includes file handle operations,
<TT
CLASS="LITERAL"
>require</TT
>, and <TT
CLASS="LITERAL"
>use</TT
> (for
external modules). There is no way to access internals of the
database server process or to gain OS-level access with the
permissions of the server process,
as a C function can do. Thus, any unprivileged database user can
be permitted to use this language.
</P
><P
> Here is an example of a function that will not work because file
system operations are not allowed for security reasons:
</P><PRE
CLASS="PROGRAMLISTING"
>CREATE FUNCTION badfunc() RETURNS integer AS $$
my $tmpfile = "/tmp/badfile";
open my $fh, '>', $tmpfile
or elog(ERROR, qq{could not open the file "$tmpfile": $!});
print $fh "Testing writing to a file\n";
close $fh or elog(ERROR, qq{could not close the file "$tmpfile": $!});
return 1;
$$ LANGUAGE plperl;</PRE
><P>
The creation of this function will fail as its use of a forbidden
operation will be caught by the validator.
</P
><P
> Sometimes it is desirable to write Perl functions that are not
restricted. For example, one might want a Perl function that sends
mail. To handle these cases, PL/Perl can also be installed as an
<SPAN
CLASS="QUOTE"
>"untrusted"</SPAN
> language (usually called
<SPAN
CLASS="APPLICATION"
>PL/PerlU</SPAN
><A
NAME="AEN45659"
></A
>).
In this case the full Perl language is available. If the
<TT
CLASS="COMMAND"
>createlang</TT
> program is used to install the
language, the language name <TT
CLASS="LITERAL"
>plperlu</TT
> will select
the untrusted PL/Perl variant.
</P
><P
> The writer of a <SPAN
CLASS="APPLICATION"
>PL/PerlU</SPAN
> function must take care that the function
cannot be used to do anything unwanted, since it will be able to do
anything that could be done by a user logged in as the database
administrator. Note that the database system allows only database
superusers to create functions in untrusted languages.
</P
><P
> If the above function was created by a superuser using the language
<TT
CLASS="LITERAL"
>plperlu</TT
>, execution would succeed.
</P
><DIV
CLASS="NOTE"
><BLOCKQUOTE
CLASS="NOTE"
><P
><B
>Note: </B
> For security reasons, to stop a leak of privileged operations from
<SPAN
CLASS="APPLICATION"
>PL/PerlU</SPAN
> to <SPAN
CLASS="APPLICATION"
>PL/Perl</SPAN
>, 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 <SPAN
CLASS="PRODUCTNAME"
>PostgreSQL</SPAN
> 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
<SPAN
CLASS="APPLICATION"
>PL/PerlU</SPAN
> and <SPAN
CLASS="APPLICATION"
>PL/Perl</SPAN
> in the same backend
process. The remedy for this is to obtain a Perl installation created
with the appropriate flags, namely either <TT
CLASS="LITERAL"
>usemultiplicity</TT
> or
both <TT
CLASS="LITERAL"
>usethreads</TT
> and <TT
CLASS="LITERAL"
>useithreads</TT
>.
For more details,see the <TT
CLASS="LITERAL"
>perlembed</TT
> manual page.
</P
></BLOCKQUOTE
></DIV
></DIV
><DIV
CLASS="NAVFOOTER"
><HR
ALIGN="LEFT"
WIDTH="100%"><TABLE
SUMMARY="Footer navigation table"
WIDTH="100%"
BORDER="0"
CELLPADDING="0"
CELLSPACING="0"
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
><A
HREF="plperl-global.html"
ACCESSKEY="P"
>Prev</A
></TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="index.html"
ACCESSKEY="H"
>Home</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
><A
HREF="plperl-triggers.html"
ACCESSKEY="N"
>Next</A
></TD
></TR
><TR
><TD
WIDTH="33%"
ALIGN="left"
VALIGN="top"
>Global Values in PL/Perl</TD
><TD
WIDTH="34%"
ALIGN="center"
VALIGN="top"
><A
HREF="plperl.html"
ACCESSKEY="U"
>Up</A
></TD
><TD
WIDTH="33%"
ALIGN="right"
VALIGN="top"
>PL/Perl Triggers</TD
></TR
></TABLE
></DIV
></BODY
></HTML
>
distrib
>
Mandriva
>
2008.1
>
x86_64
>
media
>
main-testing
>
by-pkgid
>
bab02a23fa9f3df8d66a9a3231b50245
>
files
>
410
