RetroSearch Browse

Sat Jul 1 00:33:20 CEST 2006 · https://mail.python.org/pipermail/python-dev/2006-July/066861.html

On 6/30/06, Ka-Ping Yee <python-dev at zesty.ca> wrote:
>
> On Fri, 30 Jun 2006, Brett Cannon wrote:
> > On 6/30/06, Armin Rigo <arigo at tunes.org> 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 (what I thought was paranoid) feeling.  Glad I am
> not
> > the only one who thinks that hiding file() is near impossible.
>
> If you want to do this right, it should be about *making* hiding
> possible.  If you can't hide things, it will be hard to get very far.

Well, this is only file() we are worrying about leaking out.  Stuff from
import are the worry here.

I realize that may be difficult for Python 2.x, but hiding is pretty
> essential for security.  It would be really good to keep this in mind
> for the design of Python 3k.  (It doesn't mean we can't have
> introspection,
> just that we need to agree on some discipline for how to do it.)

That's fine; I personally have no issue with tweaking the security model for
Py3K.  But I am worrying about 2.x here.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060630/172e6d14/attachment-0001.htm 

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2006-July/066861.html below:

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