Re: PL/PythonU - Mailing list pgsql-hackers

On Mon, 2008-08-04 at 13:08 -0400, David Blewett wrote:
> Hi All:
> 
> This is an off-shoot of the "Do we really want to migrate plproxy and
> citext into PG core distribution?" thread.
> 
> On the way home from PyOhio, I had a conversation with a few people
> that use Zope a lot. I happened to mention that Postgres doesn't have
> an untrusted version of pl/python and they were curious as to why.
> They directed me to Zope's Restricted Python implementation [1][2]. In
> doing some research, I found the "Pl/Python -- current maintainer?"
> [3] thread from 2006. I also found this [4] thread on the python-dev
> mailing list.
> 
> Hannu: You had mentioned bringing pl/python up to the level of some of
> the other pl's. Have you thought any more about pl/pythonu?

My recollection of old times (about python v. 1.6) was that the
restricted sandboxes had some fatal flaws. I have not followed zope's
RestrictedPython enough to have an opinion on its safety.

> David Blewett
> ------------------
> A few quotes from the python-dev thread (links at bottom):
> "Here is some context for Python-Dev.
> 
> RestrictedPython is a custom Python compiler that, when combined with a
> restricted environment, provides a sandbox safe enough to allow
> partly-trusted people to write and execute scripts on a Zope server.  It
> has been used in Zope 2 for a long time and will have a future in Zope
> 3.  The sandbox is more extensive than what the rexec module provides.
> 
> The safety of RestrictedPython has been validated in a somewhat formal
> process with Python 2.4.  Ranjith is working to validate it with Python
> 2.5." -- Shane Hathaway [5]

Will definitely look at it. Thanks.

> "No, he means the restricted Python compiler and capability-proxy
> system used by Zope.  You know, the one I always bring up whenever
> anybody says they want to implement capabilities in Python?  ;-)
> 
> Zope's restricted Python is basically a combination of a special
> compiler, __builtin__ replacements, and a proxy type.  Instead of
> using LOAD_ATTR opcodes, the compiler generates code that calls a
> special getattr() function instead, and most objects other than
> relatively-safe builtin types are wrapped in proxies that control
> what attributes can be accessed and what operations can be performed.
> 
> The restricted Python framework itself doesn't impose any particular
> security policy; proxies delegate checks to "checker" objects that
> are essentially capabilities.  Mostly, it focuses on creating a safe
> sandbox that can be expanded."  -- Phillip J. Eby [6]
> 
> 1. http://svn.zope.org/RestrictedPython/trunk/
> 2. http://svn.zope.org/zope.security/trunk/src/zope/security/untrustedpython/
> 3. http://archives.postgresql.org/pgsql-hackers/2006-02/msg01036.php
> 4. http://mail.python.org/pipermail/python-dev/2008-July/081340.html
> 5. http://mail.python.org/pipermail/python-dev/2008-July/081412.html
> 6. http://mail.python.org/pipermail/python-dev/2008-July/081347.html