<br><br><div><span class="gmail_quote">On 6/28/06, <b class="gmail_sendername">Jim Jewett</b> &lt;<a href="mailto:jimjjewett@gmail.com">jimjjewett@gmail.com</a>&gt; 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, Brett Cannon &lt;<a href="mailto:brett@python.org">brett@python.org</a>&gt; wrote:<br>&gt; On 6/28/06, Guido van Rossum &lt;<a href="mailto:guido@python.org">guido@python.org</a>&gt; wrote:<br><br>&gt; &gt; - File size should be rounded up to some block size (512 if you don't
<br>&gt; &gt; have filesystem specific information) before adding to the total.<br><br>&gt; Why?<br><br>That reflects the amount of disk I no longer have available for other<br>purposes.</blockquote><div><br>Ah, OK. <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;">&gt; &gt; - Total number of files (i.e. inodes) in existence should be capped, too.<br><br>
&gt; If you want that kind of cap, just specify individual files you are willing<br>&gt; to let people open for reading; that is your cap.&nbsp;&nbsp;Only have to worry about<br>&gt; this if you open an entire directory open for writing.
<br><br>Right, but on some systems, inodes are themselves a limited resource.</blockquote><div><br>OK. <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'm not sure how common that is.<br></blockquote><div>&nbsp;</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">&gt; &gt; - If sandboxed code is allowed to create directories, the total depth
<br>&gt; &gt; and the total path length should also be capped.<br><br>&gt; Once again, another one of those balance issues of where do we draw the line<br>&gt; in terms of simplicity ... you need to allow use of<br>&gt; the platform's OS-specific module ( 
e.g., posix) to do it since open() won't<br>&gt; let you create a directory.<br><br>I *think* this is to avoid security holes, and your solution of<br>letting the open filter out bad names should be OK, but ... what if it
<br>isn't?&nbsp;&nbsp;What if cd then mkdir will let them create something too long?<br> Do we have to wait for an OS patch?</blockquote><div><br>Then isn't that a problem with cwd() and mkdir()?<br><br>And we can play the &quot;what if&quot; scenario forever with security.&nbsp; There is always the possibility me or some originally trusted code is going to turn out to be unsafe.&nbsp; This is why I am preferring an approach of just not allowing the importation of possibly unsafe code unless you *really* trust it yourself.
<br><br>-Brett<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;">&gt; &gt; (I find reading about trusted and untrusted code confusing; a few
<br>&gt; &gt; times I've had to read a sentence three times before realizing I had<br>&gt; &gt; swapped those two words. Perhaps we can distinguish between trusted<br>&gt; &gt; and sandboxed? Or even native and sandboxed?)
<br><br>unlimited vs sandboxed?<br><br>-jJ<br></blockquote></div><br>