Re: [Python-Dev] For sandboxing: alternative to crippling file()

2006-07-01 Thread Brett Cannon
On 6/30/06, Greg Ewing [EMAIL PROTECTED] wrote: 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

Re: [Python-Dev] For sandboxing: alternative to crippling file()

2006-06-30 Thread Armin Rigo
Hi Brett, On Thu, Jun 29, 2006 at 11:48:36AM -0700, 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

Re: [Python-Dev] For sandboxing: alternative to crippling file()

2006-06-30 Thread Brett Cannon
On 6/30/06, Armin Rigo [EMAIL PROTECTED] wrote: Hi Brett,On Thu, Jun 29, 2006 at 11:48:36AM -0700, 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

Re: [Python-Dev] For sandboxing: alternative to crippling file()

2006-06-30 Thread Ka-Ping Yee
On Fri, 30 Jun 2006, Brett Cannon wrote: On 6/30/06, Armin Rigo [EMAIL PROTECTED] wrote: object.__subclasses__() [..., type 'file'] Maybe this one won't work if __subclasses__ is forbidden, but in general I think there *will* be a way to find this object. Yeah, that's been my

Re: [Python-Dev] For sandboxing: alternative to crippling file()

2006-06-30 Thread Brett Cannon
On 6/30/06, Ka-Ping Yee [EMAIL PROTECTED] wrote: On Fri, 30 Jun 2006, Brett Cannon wrote: On 6/30/06, Armin Rigo [EMAIL PROTECTED] wrote: object.__subclasses__() [..., type 'file'] Maybe this one won't work if __subclasses__ is forbidden, but in general I think there *will* be a way to find

Re: [Python-Dev] For sandboxing: alternative to crippling file()

2006-06-30 Thread Greg Ewing
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

[Python-Dev] For sandboxing: alternative to crippling file()

2006-06-29 Thread Brett Cannon
I have gotten some questions from people about why cripple 'file' (and probably 'socket' if they cared), asking whey I didn't just remove the 'file' built-in from built-ins. Problem is that I still want to provide some protection for files. So an option I have been thinking of is making sure

Re: [Python-Dev] For sandboxing: alternative to crippling file()

2006-06-29 Thread A.M. Kuchling
On Thu, Jun 29, 2006 at 11:48:36AM -0700, Brett Cannon wrote: My worry, as has been from the start, is containing 'file'. The ``del __builtins__`` bug for 'rexec' started me as skittish towards hiding stuff from the built-in namespace. And knowing how easy it tends to be to get at objects

Re: [Python-Dev] For sandboxing: alternative to crippling file()

2006-06-29 Thread Brett Cannon
On 6/29/06, A.M. Kuchling [EMAIL PROTECTED] wrote: On Thu, Jun 29, 2006 at 11:48:36AM -0700, Brett Cannon wrote: My worry, as has been from the start, is containing 'file'.The ``del __builtins__`` bug for 'rexec' started me as skittish towards hiding stuff from the built-in namespace.And knowing

Re: [Python-Dev] For sandboxing: alternative to crippling file()

2006-06-29 Thread Benji York
A.M. Kuchling wrote: This thought was sparked by the piece on failure-oblivious computing in today's Linux Weekly News about this paper: http://www.usenix.org/events/osdi04/tech/rinard.html. The paper is also available from one of the authors at