[Python-Dev] new security doc using object-capabilities

[Brett Cannon]

On 7/20/06, Giovanni Bajo <rasky at develer.com> wrote:
>
> Brett Cannon wrote:
>
> >>
>
> http://svn.python.org/view/python/branches/bcannon-sandboxing/securing_python.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 safe_eval recipe (a separate thread which
> interrupts the script through thread.interrupt_main()) 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