Normalmente, PL/Perl se instala como un lenguaje de programación “de confianza” (trusted)
llamado plperl. En esta configuración, ciertas operaciones de Perl
están deshabilitadas para preservar la seguridad. En general, las
operaciones restringidas son aquellas que interactúan con el
entorno. Esto incluye operaciones con manejadores de archivos (file handles),
require y use (para
módulos externos). No hay forma de acceder a los aspectos internos del
proceso del servidor de la base de datos ni de obtener acceso a nivel de sistema operativo con los
privilegios del proceso del servidor,
como puede hacerlo una función C. Por lo tanto, a cualquier usuario de la base de datos sin privilegios se le puede
permitir usar este lenguaje.
El PL/Perl de confianza depende del módulo Opcode de Perl para
preservar la seguridad.
Perl
documenta
que el módulo no es efectivo para el caso de uso de PL/Perl de confianza. Si
tus necesidades de seguridad son incompatibles con la incertidumbre de esa advertencia,
considera ejecutar REVOKE USAGE ON LANGUAGE plperl FROM
PUBLIC.
Aquí hay un ejemplo de una función que no funcionará porque las operaciones del sistema de archivos no están permitidas por razones de seguridad:
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;
La creación de esta función fallará ya que el uso de una operación prohibida será detectado por el validador.
A veces es deseable escribir funciones Perl que no estén
restringidas. Por ejemplo, uno podría querer una función Perl que envíe
correo. Para manejar estos casos, PL/Perl también se puede instalar como un
lenguaje “sin confianza” (untrusted) (usualmente llamado
PL/PerlU).
En este caso, el lenguaje Perl completo está disponible. Al instalar el
lenguaje, el nombre del lenguaje plperlu seleccionará
la variante PL/Perl sin confianza.
El escritor de una función PL/PerlU debe tener cuidado de que la función no pueda usarse para hacer nada no deseado, ya que podrá hacer cualquier cosa que pueda hacer un usuario que haya iniciado sesión como el administrador de la base de datos. Ten en cuenta que el sistema de base de datos permite solo a los superusuarios de la base de datos crear funciones en lenguajes sin confianza.
Si la función anterior fuera creada por un superusuario utilizando el lenguaje
plperlu, la ejecución tendría éxito.
De la misma manera, los bloques de código anónimos escritos en Perl pueden usar
operaciones restringidas si el lenguaje se especifica como
plperlu en lugar de plperl, pero el invocador
debe ser un superusuario.
Mientras que las funciones PL/Perl se ejecutan en un intérprete Perl separado para cada rol SQL, todas las funciones PL/PerlU ejecutadas en una sesión de base de datos se ejecutan en un único intérprete Perl (que no es ninguno de los utilizados para las funciones PL/Perl). Esto permite que las funciones PL/PerlU compartan datos libremente, pero no puede ocurrir comunicación entre las funciones PL/Perl y PL/PerlU.
Perl no puede admitir múltiples intérpretes dentro de un proceso a menos que
se haya compilado con las opciones adecuadas, a saber, ya sea
usemultiplicity o useithreads.
(usemultiplicity es preferible a menos que realmente necesites
usar hilos (threads). Para más detalles, consulta la página de manual
perlembed).
Si PL/Perl se usa con una copia de Perl que no fue construida
de esta manera, entonces solo es posible tener un intérprete Perl por
sesión, por lo que cualquier sesión solo puede ejecutar funciones
PL/PerlU, o funciones PL/Perl
que sean todas llamadas por el mismo rol SQL.