Normalement, PL/Perl est installé en tant que langage de programmation de
« confiance », de nom plperl. Durant cette installation,
certaines commandes Perl sont désactivées pour préserver la sécurité. En
général, les commandes qui interagissent avec l'environnement sont
restreintes. Cela inclut les commandes sur les descripteurs de fichiers,
require et use (pour les modules
externes). Il n'est pas possible d'accéder aux fonctions et variables
internes du processus du serveur de base de données ou d'obtenir un accès au
niveau du système d'exploitation avec les droits du processus serveur, tel
qu'une fonction C peut le faire. Ainsi, n'importe quel utilisateur sans
droits sur la base de données est autorisé à utiliser ce langage.
Le langage PL/Perl de confiance se base sur le module
Opcode de Perl pour préserver la sécurité.
Perl
documente
que ce module n'est pas efficace pour le cas d'utilisation d'un
PL/Perl de confiance. Si vos besoins en sécurité sont incompatibles
avec l'incertitude de cet avertissement, considérez d'exécuter
REVOKE USAGE ON LANGUAGE plperl FROM PUBLIC.
Voici l'exemple d'une fonction qui ne fonctionnera pas car les commandes système ne sont pas autorisées pour des raisons de sécurité :
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 création de cette fonction échouera car le validateur détectera l'utilisation par cette fonction d'une opération interdite.
Il est parfois souhaitable d'écrire des fonctions Perl qui ne sont pas
restreintes. Par exemple, on peut souhaiter vouloir envoyer des courriers
électroniques. Pour supporter ce cas de figure, PL/Perl peut aussi être
installé comme un langage « douteux » (habituellement nommé
PL/PerlU
).
Dans ce cas, la totalité du langage Perl est accessible. Lors de
l'installation du langage, le nom
du langage plperlu sélectionnera la version douteuse de
PL/Perl.
Les auteurs des fonctions PL/PerlU doivent faire attention au fait que celles-ci ne puissent être utilisées pour faire quelque chose de non désiré car cela donnera la possibilité d'agir comme si l'on possédait les privilèges d'administrateur de la base de données. Il est à noter que le système de base de données ne permet qu'aux superutilisateurs de créer des fonctions dans un langage douteux.
Si la fonction ci-dessus a été créée par un superutilisateur en utilisant
le langage plperlu, l'exécution de celle-ci réussira.
De la même façon, les blocs de procédure anonymes écris en perl peuvent utiliser
les opérations restreintes si le langage est spécifié comme
plperlu plutôt que plperl, mais l'appelant
doit être un superutilisateur.
Bien que les fonctions PL/Perl s'exécutent dans un interpréteur Perl séparé pour chaque rôle SQL, toutes les fonctions PL/PerlU exécutées dans la même session utilisent un seul interpréteur Perl (qui n'est pas un de ceux utilisés par les fonctions PL/Perl). Ceci permet aux fonctions PL/PerlU de partager librement des données, mais aucune communication ne peut survenir entre des fonctions PL/Perl et PL/PerlU.
Perl ne peut pas supporter plusieurs interpréteurs à l'intérieur d'un seul
processus sauf s'il a été construit avec les bonnes options, soit
usemultiplicity soit useithreads.
(usemultiplicity est préféré sauf si vous avez besoin
d'utiliser des threads. Pour plus de détails, voir la page de manuel de
perlembed.) Si
PL/Perl est utilisé avec une copie de Perl qui
n'a pas été construite de cette façon, alors seul un interpréteur Perl par
session sera disponible, et donc une session ne pourra exécuter soit que
des fonctions PL/PerlU, soit que des fonctions
PL/Perl qui sont appelées par le même rôle SQL.