Postgresql 中文操作指南

45.5. Trusted and Untrusted PL/Perl #

通常，PL/Perl 被安装为名为 plperl 的“受信任”编程语言。在此设置中，某些 Perl 操作被禁用以保护安全。通常，受限的操作是与环境交互的操作。这包括文件句柄操作、require 和 use（用于外部模块）。无法像 C 函数那样访问数据库服务器进程的内部或以服务器进程的权限获得操作系统级访问。因此，任何没有特权的数据库用户都可以被允许使用此语言。

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 can 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 caught by the validator.

有时希望编写不受限制的 Perl 函数。例如，可能需要一个发送邮件的 Perl 函数。要处理这些情况，PL/Perl 还可以作为“不受信任”的语言（通常称为 PL/PerlU）进行安装。在这种情况下，整个 Perl 语言都可以使用。在安装该语言时，语言名称 plperlu 将选择不受信任的 PL/Perl 变体。

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. When installing the language, the language name plperlu will select the untrusted PL/Perl variant.

PL/PerlU 函数的编写者必须注意，该函数不能被用来做任何不需要的事情，因为它将能够做任何以数据库管理员身份登录的用户可以做的事情。请注意，数据库系统只允许数据库超级用户创建不受信任语言中的函数。

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.

如果上述函数是由超级用户使用语言 plperlu 创建的，则执行将成功。

If the above function was created by a superuser using the language plperlu, execution would succeed.

同样，以 Perl 编写的匿名代码块可以使用受限操作，如果语言指定为 plperlu 而不是 plperl，但调用者必须是超级用户。

In the same way, anonymous code blocks written in Perl can use restricted operations if the language is specified as plperlu rather than plperl, but the caller must be a superuser.

Note

虽然 PL/Perl 函数针对每个 SQL 角色在一个独立的 Perl 解释器中运行，但给定会话中执行的所有 PL/PerlU 函数在一个单一的 Perl 解释器中运行（它不是用于 PL/Perl 函数的任何一个）。这允许 PL/PerlU 函数自由共享数据，但 PL/Perl 和 PL/PerlU 函数之间不能进行任何通信。

While PL/Perl functions run in a separate Perl interpreter for each SQL role, all PL/PerlU functions executed in a given session run in a single Perl interpreter (which is not any of the ones used for PL/Perl functions). This allows PL/PerlU functions to share data freely, but no communication can occur between PL/Perl and PL/PerlU functions.

Note

除非使用适当的标志构建 Perl（即_usemultiplicity_或_useithreads_），否则 Perl 无法在一个进程中支持多个解释器。(_usemultiplicity_更可取，除非您实际需要使用线程。有关更多详细信息，请参阅 perlembed 手册页。)如果将 PL/Perl 与不是以这种方式构建的 Perl 副本一起使用，则每个会话只能有一个 Perl 解释器，因此任何一个会话只能执行 PL/PerlU 函数或由相同 SQL 角色调用的所有 PL/Perl 函数。

Perl cannot support multiple interpreters within one process unless it was built with the appropriate flags, namely either usemultiplicity or useithreads. (usemultiplicity is preferred unless you actually need to use threads. For more details, see the perlembed man page.) If PL/Perl is used with a copy of Perl that was not built this way, then it is only possible to have one Perl interpreter per session, and so any one session can only execute either PL/PerlU functions, or PL/Perl functions that are all called by the same SQL role.