On 6/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
I understand that. What I am saying is that by specifying only specific files to open you cap the number of open inodes you create. If you only have room for five more inodes for the program to open, only specify five specific files for the sandboxed interpreter (see? I learn fast =) that it can open.
I would rather not handle that and just warn people that if they allow full use of 'os' that they better know what they are doing.
-Brett
On 6/28/06, Brett Cannon <[EMAIL PROTECTED]> wrote:
> On 6/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > - File size should be rounded up to some block size (512 if you don't
> > have filesystem specific information) before adding to the total.
>
> Why?
Because that's how filesystems work. Allocations are in terms of block
sizes. 1000 files of 1 byte take up the same space as 1000 files of
512 bytes (in most common filesystems anyway -- I think Reiserfs may
be different).
> > - Total number of files (i.e. inodes) in existence should be capped, too.
>
> 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.
I'm not talking about filedescriptors (although that's another
cappable resource); I'm talking about number of files in the
filesystem. Most unix filesystems have a limit; I've run into it
occasionally when I had a really large partition with not enough
inodes configured and I was creating lots of tiny files. See df(1).
I understand that. What I am saying is that by specifying only specific files to open you cap the number of open inodes you create. If you only have room for five more inodes for the program to open, only specify five specific files for the sandboxed interpreter (see? I learn fast =) that it can open.
> > - If sandboxed code is allowed to create directories, the total depth
> > and the total path length should also be capped.
>
> 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.
>
> I really want to keep the settings and setup simple. I don't want to
> overburden people with a ton of security settings.
Well, I prefixed it with "if you want to allow directory creation". If
you don't allow that, fine. But if you do allow that (and it's an
easily controlled operation just like file creation) I've given you
some things to watch out for. I once ran into a situation where a
script had gone off into deep recursion and created a near-infinite
hierarchy of directories that rm -r couldn't remove (because it
constructs absolute paths that exceeded MAXPATH).
I would rather not handle that and just warn people that if they allow full use of 'os' that they better know what they are doing.
-Brett
> > (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?)
> Fair enough. When I do the next draft I will make them more distinctive
> (probably "trusted" and "sandboxed").
Great!
--
--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
