Thread: PL/PythonU
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? 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] "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
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
Hannu Krosing wrote: > 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. Personally I'm also constantly mentioning it :-) >> 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. Yes, the old sandbox (restricted execution and bastion) used a realatively naive approach of basically limiting only imports and iirc. some file access objects. That beeing not really bullet proof so these modules have been removed. This should not be confused with the different approach restricted python uses and which proofes to be successfull to date. Regards Tino