Subject: Minor changed needed to doc on untrusted pl/perl example

From: Bob <[email-masked]>
Date: Fri, 21 Oct 2005 13:06:05 -0500

I know this is minor but we all long for perfection.:)

The current doc shows
37.5. Trusted and Untrusted PL/Perl

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 $$
    open(TEMP, ">/tmp/badfile");
    print TEMP "Gotcha!\n";
    return 1;
$$ LANGUAGE plperl;

I believe the code snippet should look like this for it to work correctly:

CREATE FUNCTION badfunc() RETURNS integer AS $$
    open(TEMP, ">/tmp/badfile");
    print TEMP "Gotcha!\n";
    close(TEMP);
    return 1;
$$ LANGUAGE plperl;

---

From: Michael Fuhr <[email-masked]>
Date: Fri, 21 Oct 2005 14:51:16 -0600

>     open(TEMP, ">/tmp/badfile");

The function should work without an explicit close (or it would,
but for the security check).  The file should appear on disk
immediately after the open, although the data might not be flushed
to disk until the file is actually closed, such as when the calling
session's postmaster exits (that's how a plperlu version behaves
on my test system, anyway).  Not that I disagree with adding an
explicit close, but the example should still "work" without it.

-- 
Michael Fuhr