[Python-Dev] Bastion too (was: Cross compiling)
Mon, 6 Jan 2003 15:26:34 +0100
From: "Guido van Rossum" <firstname.lastname@example.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" <email@example.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.
> > 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
> > 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("""exec "open('c:/evil','w')" in g""")
like opening a file for writing.