Sandboxing [Was Re: killing thread ?]
Terry Reedy
tjreedy at udel.edu
Fri Jan 24 18:21:09 EST 2003
"Jack Diederich" <jack at performancedrivers.com> wrote in message
news:mailman.1043432149.5693.python-list at python.org...
> On Fri, Jan 24, 2003 at 12:44:24PM -0500, Jp Calderone wrote:
> > On Fri, Jan 24, 2003 at 07:52:08AM -0800, Paul Rubin wrote:
> > > Peter Hansen <peter at engcorp.com> writes:
> > > > If you're worried about some kind of denial of service type
> > > > thing with code written by someone else: you're out of luck.
> > > > Don't use Python. (Or, better yet, get over the worry and
just
> > > > accept this possibility.)
> > >
> > > Wha? Python provides the rexec and bastion modules specifically
to
> > > have a way to run hostile code in a sandbox. So what kind of
advice
> > > is "don't use Python"? If sandboxed code can be prevented from
> > > accessing sensitive data or doing i/o, but can't be prevented
from
> > > looping unkillably, that's a bug in Python.
> >
> > Yes, that's why Python provides them. But this misconception
(that they
> > work) is also why it will soon -not- provide them :P And neither
RExec nor
> > Bastion ever protected you against "while 1: pass"
Hmmm. Disable 'while': force use of for loops, and limit list
lengths, and recursion depth and ....
>> or "100L ** 100L ** 100L ** 100L ** 100L".
Hmmm. Remove longs. But then language is not quite Python.
> If you've ever worked on an LPC MUD or thought about implementing
one
> you have to deal with giving 'untrusted' users code-level access to
the system.
I have sometimes thought I would like to play (or write) a game
user-scriptable in Python. But I keep seeing problems like the above.
Removing parts of the language, to make it *not* Turing-complete, as
well as some builtin functions, is only thing I can think of.
Terry
More information about the Python-list
mailing list