Showing content from http://mail.python.org/pipermail/python-dev/attachments/20060628/42d76a73/attachment.htm below:
<br><br><div><span class="gmail_quote">On 6/28/06, <b class="gmail_sendername">Guido van Rossum</b> <<a href="mailto:guido@python.org">guido@python.org</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On 6/28/06, Jim Jewett <<a href="mailto:jimjjewett@gmail.com">jimjjewett@gmail.com</a>> wrote:<br>> On 6/27/06, Neal Norwitz <<a href="mailto:nnorwitz@gmail.com">nnorwitz@gmail.com</a>> wrote:<br>> > On 6/27/06, Brett Cannon <
<a href="mailto:brett@python.org">brett@python.org</a>> wrote:<br>> > ><br>> > > > (5) I think file creation/writing should be capped rather than<br>> > > > binary; it is reasonable to say "You can create a single temp file up
<br>> > > > to 4K" or "You can create files, but not more than 20Meg total".<br>><br>> > > That has been suggested before. Anyone else like this idea?<br>><br>> > [ What exactly does the limit mean? bytes written? bytes currently stored? bytes stored after exit?]
<br>><br>> IMHO, I would prefer that it limit disk consumption; a deleted or<br>> overwritten file would not count against the process, but even a<br>> temporary spike would need to be less than the cap.<br><br>
Some additional notes:<br><br>- File size should be rounded up to some block size (512 if you don't<br>have filesystem specific information) before adding to the total.</blockquote><div><br>Why? <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
- Total number of files (i.e. inodes) in existence should be capped, too.</blockquote><div><br>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.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">- If sandboxed code is allowed to create dierctories, the total depth<br>and the total path length should also be capped.
</blockquote><div><br>Once again, another one of those balance issues of where do we draw the line in terms of simplicity in the setting compared to controlling every possible setting people will want (especially, it seems, when it comes to writing to disk). And if you want to allow directory writing, 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.<br><br>I really want to keep the settings and setup simple. I don't want to overburden people with a ton of security settings.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
(I find reading about trusted and untrusted code confusing; a few<br>times I've had to read a sentence three times before realizing I had<br>swapped those two words. Perhaps we can distinguish between trusted<br>and sandboxed? Or even native and sandboxed?)
<br><br><br></blockquote></div><br><br>Fair enough. When I do the next draft I will make them more distinctive (probably "trusted" and "sandboxed").<br><br>-Brett<br>
RetroSearch is an open source project built by @garambo
| Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4