On 6/28/06, Jim Jewett <[EMAIL PROTECTED]> wrote: > On 6/27/06, Neal Norwitz <[EMAIL PROTECTED]> wrote: > > On 6/27/06, Brett Cannon <[EMAIL PROTECTED]> 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/) _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
