Re: [pygame] Scripting language

[JoN <jon@xxxxxxxxxxxxxxxxxx>]

This is something I'm very interested in.
I'm wondering if Van Rossum is thinking about this these days, but he's been
close-lipped about it on the searches I've done so far.

You can restrict access to imported classes and methods by fiddling with
Properties, kinda easily enough, but then how to apply an access model to it?
Particularly in a PyThreads environment, which is what I'm looking at.

Guess this is well off-topic for pygame but thought I'd throw some petrol on the
fire.

Jon


Quoting Brandon N <kordova@xxxxxxxxx>:

> I've been reading up on perspective broker since you emailed it and I  
> think a solution of that sort is the most likely that I will end up  
> with.
> 
> As for the examples you have posted, I had a rudimentary Python-like  
> scripting language I've been building that is translated to Python  
> after validation (against things like forever loops, unregistered  
> function calls and the like), but I agree that no amount of work will  
> really close the gaping holes that exist for abuse my malicious and  
> unknowing users.
> 
> Cheers,
>    Brandon
> 
> On Dec 18, 2006, at 7:14 PM, robomancer wrote:
> 
> >> I like the way Brian just sent before. I dont know any language that
> >> restricts its usage (would be neat feature for certain projects).
> >
> > Perl has "taint mode".  When enabled, Perl won't let you do any
> > "dangerous" operations (file accesses, system calls, etc) on data that
> > originally came from the user and hasn't been processed to remove its
> > "taintedness".
> >
> > On the other hand, allowing people to run arbitrary code on your
> > machine is a Bad Idea even if you *can* ensure that the filesystem
> > isn't touched.  What if they send any of the following?
> >
> > while True:
> >  pass
> >
> > def fib(n):
> >  return fib(n-1) + fib(n-2)
> > fib(1000000)
> >
> > def steal_data():
> >  send_to_client("127.0.0.1", pickle.dump(confidential.data.structure)
> >
> > There are just so many ways to exploit arbitrary code execution, from
> > malicious data corruption to denial-of-service to buffer-overflow
> > exploits (yes, this is possible even from within Python, if you use
> > any buggy C extension modules)... it's *really* not a good idea.  A
> > lot of very smart people have worked hard to solve this sort of
> > problem, and not made much progress.
> >
> > I either recommend having an explicit server/client API and forcing
> > people to use that API (whether it's invoked via Perspective Broker as
> > I suggested earlier, or something more standard like XML-RPC, CORBA,
> > or SOAP), or not allowing a "scripting language" at all, instead
> > opting for something like customizable configuration files that aren't
> > Turing-complete.
> 
> 




--------------------------------------------------------------------
Come and visit Web Prophets Website at http://www.webprophets.net.au