open == file considered harmful (Re: [Python-Dev] RE: rexec.pyunuseable)

Guido van Rossum guido at
Thu Dec 18 10:38:03 EST 2003

> >>It would be a lot better if we could get away from the idea
> >>of a "restricted mode" in the sense of a flag somewhere that
> >>a bunch of things have to take notice of in order to behave
> >>securely, because that model of security is prone to springing
> >>leaks -- as happened in a big way when new-style classes were
> >>introduced.
> > 
> > Right.  Restricted mode currently uses both paradigms: you only have
> > access to the builtins that are given to you in the __builtins__ dict
> > -- this is pure capability stuff, and IMO it works well -- and some
> > builtin operations behave differently when you're in restricted mode
> > -- this is the ACL stuff, and Samuele revealed serious holes in it.
> What if instead of 'builtin behaves differently in restricted mode' we 
> had 'restricted __builtins__ contains a DIFFERENT builtin, that happens 
> to have the same name'?
> That is, in addition to the ability to simply deny access to a specific 
> builtin function or class, there was the ability to _replace_ one before 
> giving it to the restricted code.

Oh, there is, of course.

Sorry, I wasn't clear.  There are a few operations that are *not*
spelled as built-in function calls that have to be restricted.  For
example, every object supports getting obj.__dict__ -- but in
restricted mode you don't want to allow this.  The Python source
currently checks for "was I called from restricted mode" to deny such
operations.  The holes that Samuele revealed had to do with tricking
unrestricted code into invoking unsafe things with arbitrary arguments
controlled by the restricted code.

--Guido van Rossum (home page:

More information about the Python-Dev mailing list