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 backend process or to gain OS-level access with the
permissions of the PostgreSQL user ID,
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 '
open(TEMP, ">/tmp/badfile");
print TEMP "Gotcha!\n";
return 1;
' LANGUAGE plperl;
The creation of the function will succeed, but executing it will not.
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.
