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.
