Three hours ago, Jukka Tuominen wrote:
>
> Thanks Eli, much appreciated!
>
> By means of just limiting provided functions, the latter approach
> seems bullet-proof (although lacking sandbox characteristics that
> net-repl partly does already AFAIU).
>
> If however, I would choose the sandbox approach, can you think of
> any way to break into the system by utilizing some 'invisible'
> features? Is this also bullet-proof?
The sandbox is more proof in a sense that it requires explicit
permission for things like FS access or taking too long, or using a
lot of memory. For example, if your `f1' handler happens to consume
too much memory, running it inside the sandbox will lead to an
exception rather than to crashing the server. Worse, your handlers
might be open to code injection that you didn't anticipate. So it can
basically protect you against bugs in your own code.
But if you trust your code to be safe, then the explicit dispatching
is overall simpler to deal with.
An hour and a half ago, Jukka Tuominen wrote:
>
> this works nicely in Linux (where intented), but when tested inside
> Win XP/ Racket 5.1., it gives the following error:
>
> file-exists?: `exists' access denied for C:\Program
> Files\Racket\lib\libeay32.dll
A sandbox requires explicit permission to access any file (and with
different kind of access).
But the default should allow reading files in the racket tree, so this
might be a bug.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________________________________
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/users
