[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