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

[Brett Cannon]

On 6/30/06, Greg Ewing <greg.ewing at canterbury.ac.nz> 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 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.


So require use of open() to open a file and then put the access restrictions
in open() while turning off the constructor for file?

Seems reasonable.  It basically shifts the access restrictions to open()
instead of 'file'.  For some reason this proposal makes me want to remove
the checks in read/write methods as well.  That way there is only open()
that needs to do the checks and 'file' can have the constructor crippled and
that be it.  Really minimize the impact of code on 'file' itself.

Do people think that having the restriction checks for every read/write
method is necessary?  I originally thought of doing that so that if an open
file object leaked into a restricted interpreter by accident there would
still be proper protections, but perhaps that should not be the
resopnsibility of 'file' and instead should be more up to modules not
passing back exposed 'file' objects into code.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-dev/attachments/20060701/1087426f/attachment.html