Home Original page

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

Guido van Rossum guido at python.org
Wed Jun 28 18:49:23 CEST 2006 
On 6/28/06, Jim Jewett <jimjjewett at gmail.com> wrote:
> On 6/27/06, Neal Norwitz <nnorwitz at gmail.com> wrote:
> > On 6/27/06, Brett Cannon <brett at python.org> wrote:
> > >
> > > > (5)  I think file creation/writing should be capped rather than
> > > > binary; it is reasonable to say "You can create a single temp file up
> > > > to 4K" or "You can create files, but not more than 20Meg total".
>
> > > That has been suggested before.  Anyone else like this idea?
>
> > [ What exactly does the limit mean?  bytes written?  bytes currently stored?  bytes stored after exit?]
>
> IMHO, I would prefer that it limit disk consumption; a deleted or
> overwritten file would not count against the process, but even a
> temporary spike would need to be less than the cap.

Some additional notes:

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

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

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

(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?)

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-Dev mailing list