[Python-Dev] new security doc using object-capabilities (original) (raw)

Brett Cannon brett at python.org
Thu Jul 20 20:10:29 CEST 2006

On 7/20/06, Giovanni Bajo <rasky at develer.com> wrote:

Brett Cannon wrote: >> http://svn.python.org/view/python/branches/bcannon-sandboxing/securingpython.txt?rev=50717&view=log >> . >> >> How do you plan to handle CPU-hogs? Stuff like execution of a >> gigantic integer multiplication. > > > I don't. =) Protecting the CPU is damn hard to do in any form of > portable fashion. And even getting it to work on an OS you do know > the details of leads to probably an interrupt implementation and > that doesn't sound fun. I think the trick used by the safeeval recipe (a separate thread which interrupts the script through thread.interruptmain()) shows that, in most cases, it's possible to make sure that an embedded script does not take too long to execute. Do you agree that this usage case ("allow me to timeout an embedded script") is something which would be a very good start in the right direction?

Probably. I just don't feel like worrying about it right now. =)

Now, I wonder, in a restricted execution environment such as that depicted

in your document, how many different ways are there to make the Python interpreter enter a long calcolation loop which does not release the GIL? I can think of bignum*bignum, bignum**bignum or similar mathematical operations, but there are really a few. If we could make those release the GIL (or poll some kind of watchdog used to abort them, pretty much like they normally poll CTRL+C), then the same trick used by the recipe could be used.

Well, any work that does most of its calculation within C code and that does not touch base with the interpreter on a semi-regular basis would need to relesae the GIL.

-Brett -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-dev/attachments/20060720/d60aea40/attachment.htm

More information about the Python-Dev mailing list