[Python-Dev] For sandboxing: alternative to crippling file() (original) (raw)
Greg Ewing greg.ewing at canterbury.ac.nz
Sat Jul 1 06:59:19 CEST 2006
- Previous message: [Python-Dev] doc for new restricted execution design for Python
- Next message: [Python-Dev] For sandboxing: alternative to crippling file()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Brett Cannon wrote:
1) Is removing 'file' from the builtins dict in PyInterpreterState (and maybe some other things) going to be safe enough to sufficiently hide 'file' confidently (short of someone being stupid in their C extension module and exposing 'file' directly)?
2) Changing open() to return C-implemented delegate objects for files (and thus won't type check, but this is Python so I am not worried about that too much) and delegate socket objects for IP and URL addresses.
My suggestion is to change things so that the constructor of the file type doesn't open files (at least in restricted mode). Then it wouldn't matter if untrusted code had real file objects, as they couldn't use them to get access to any other files.
-- Greg
- Previous message: [Python-Dev] doc for new restricted execution design for Python
- Next message: [Python-Dev] For sandboxing: alternative to crippling file()
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]