AW: [mailinglist] [Python-de] Sandkastenspiele

Martin v. Löwis martin at v.loewis.de
Sam Jun 14 12:51:52 EDT 2003


Dinu Gherman <dinu at mac.com> writes:

> Wie ich sehe, sind da keinerlei Wrapper z.B. um open oder __import__
> drin, sondern diese Funktionen werden ersetzt durch load_*-Methoden
> der SandBox, richtig? Heisst das, man kann z.B. gar kein open() mehr
> verwenden, oder gibt's dazu einfach nur keinen Testcode?

Nein. Der Beispielcode macht ja tatsächlich open(), nur dass es da
halt file() heißt.

Der SandBox-Code baut natürlich massiv auf restricted execution auf,
sonst könnte man vom ProxyObject einfach auf __dict__ zugreifen, und
von da aus sich ordentliche builtins beschaffen.

Damit hat er die gleichen Probleme wie rexec: Man probiere einmal

print type(3).__bases__[0].__subclasses__()

innerhalb einer Sandbox.

> Ich bekomme das mit Wrappern fuer open etc. hin, aber die um-
> wickelten Funktionen gibt es dann immer noch. 

Den Wrapper für open hinzubekommen ist nicht so einfach.

def new_open(name, opts):
  if not check_name_and_opt(name, opts):
     raise BadNameOrOpts
  return open(name, opts)

leistet jedenfalls nicht das Verlangte, da dann jemand durchaus

open(good_name).__class__(bad_name, 'w')

aufrufen kann (was noch kein Problem ist, weil restricted execution
den Aufruf des File-Konstruktors nicht zulässt - im Allgemeinen kann
man aber keinen sicheren Wrapper um eine newstyle class schreiben,
sofern diese die normale Konstruktorsyntax unterstützt).

> Man koennte vermutlich auch __import__, open und file ganz in Python
> schreiben, was wohl kein Spass sein duerfte. Aber... obwohl, kann
> man??

__import__ kann man ganz in Python schreiben, wenn es keine extension
modules laden können soll. open() kann man in Python schreiben, indem
man es auf os.open abbildet.

Ciao,
Martin