Normally, PL/Perl is installed as a “trusted” programming
language named plperl. 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,
require, and use (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 may
be permitted to use this language.
Here is an example of a function that will not work because file system operations are not allowed for security reasons:
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;
The creation of this function will fail as its use of a forbidden operation will be be caught by the validator.
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
“untrusted” language (usually called
PL/PerlU).
In this case the full Perl language is available. If the
createlang program is used to install the
language, the language name plperlu will select
the untrusted PL/Perl variant.
The writer of a PL/PerlU 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.
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.