[Python-Dev] For sandboxing: alternative to crippling file()
Brett Cannon
brett at python.org
Sat Jul 1 00:33:20 CEST 2006
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
More information about the Python-Dev
mailing list