> > [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.
> a bastionized empty instance b of a classic class, a restricted enviroment...
--Guido van Rossum (home page: http://www.python.org/~guido/)
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