Fix for PlPython trust problems

Hello,

Attached is a patch for PlPython from version 7.2b2 that addresses all
'trust' problem that were discovered during my security audit of the module.
I've gotten some positive feedback on this patch and have tested it myself
in several fairly demanding applications for several days.  This patch
primarily removes all read-only filesystem access that is made available by
the default configuration of the restricted execution environment used in
PlPython.  Virtually all operating system and filesystem write-access were
already prohibited.

Here are the details of what I have added or changed:

    1) Overrode the default RExec (restricted execution object) 'r_open'
       function, which controls all file-open calls.  Previously, it
       would allow read-only access and throw an exception, otherwise.
       I have added a new 'r_open' handler that unconditionally throws
       an exception instead of allowing any file access from within the
       Python interpreter.

    2) Removed access to previously available read-only POSIX system
       functions (including fstat, listdir, lstat, readlink, stat,
       times, uname, getpid, getppid, getcwd, getuid, getgid, geteuid,
       getegid).  Note that exec, system, unlink, etc. were already
       excluded.

    3) Tweaked which elements of the 'sys' module are available to hide
       path and system configuration information about the Python
       installation.  This information is unnecessary in an embedded
       environment and may have given an attacker useful system
       information.

    4) Re-arranged the RExec initialization for clarity, improved
       performance and extensibility.  Instead of configuring instances
       of the RExec class each time we instantiate it, now we simply
       alter the class definition so that all instances share the
       settings automatically.

    5) Cleaned up static declarations a bit.

    6) Added test cases to exercise the improved sandbox.

    7) Added a few extra modules to the importable list since they are
       generally regarded to be safe and useful.

I've tested this patch with Python 2.0, 2.1 and 2.2b1.  I have no idea if it
previously worked with 1.5.x, or if it will now.

Tom Lane has expressed concern about shipping PlPython as a trusted language
in PostgreSQL 7.2 in light of these and other possibly undetected security
holes.  I believe that my audit has covered all the bases, though I welcome
comments, scrutiny and review.  So long as the Python installation has not
been subverted, I believe that this patch makes PlPython fairly safe.

Regards,
-Kevin Jacobs

--
Kevin Jacobs
The OPAL Group - Enterprise Systems Architect
Voice: (216) 986-0710 x 19         E-mail: jacobs@theopalgroup.com
Fax:   (216) 986-0714              WWW:    http://www.theopalgroup.com