[Python-Dev] doc for new restricted execution design for Python

[Jim Jewett]

On 6/28/06, Brett Cannon <brett at python.org> wrote:
> On 6/28/06, Guido van Rossum <guido at python.org> wrote:

> > - File size should be rounded up to some block size (512 if you don't
> > have filesystem specific information) before adding to the total.

> Why?

That reflects the amount of disk I no longer have available for other
purposes.

> > - Total number of files (i.e. inodes) in existence should be capped, too.

> If you want that kind of cap, just specify individual files you are willing
> to let people open for reading; that is your cap.  Only have to worry about
> this if you open an entire directory open for writing.

Right, but on some systems, inodes are themselves a limited resource.
I'm not sure how common that is.

> > - If sandboxed code is allowed to create directories, the total depth
> > and the total path length should also be capped.

> Once again, another one of those balance issues of where do we draw the line
> in terms of simplicity ... you need to allow use of
> the platform's OS-specific module ( e.g., posix) to do it since open() won't
> let you create a directory.

I *think* this is to avoid security holes, and your solution of
letting the open filter out bad names should be OK, but ... what if it
isn't?  What if cd then mkdir will let them create something too long?
 Do we have to wait for an OS patch?

> > (I find reading about trusted and untrusted code confusing; a few
> > times I've had to read a sentence three times before realizing I had
> > swapped those two words. Perhaps we can distinguish between trusted
> > and sandboxed? Or even native and sandboxed?)

unlimited vs sandboxed?

-jJ