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 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

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__()> > [..., ] > >> > Maybe this one won't work if __subclasses__ is forbidden, but in general> > I think there *will* be

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__() > > [..., ] > > > > 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 b

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 som

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-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 http://www.cag.lcs.mit.edu/~rinard/paper/osd

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

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

[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 'file