[racket] Limiting net-repl provided functions

From: Jukka Tuominen (jukka.tuominen at finndesign.fi)
Date: Tue Jun 28 07:52:04 EDT 2011

> -----Original Message-----
> From: Eli Barzilay [mailto:eli at barzilay.org]
> Sent: 28 June 2011 13:56
> To: Jukka Tuominen
> Cc: Sam Tobin-Hochstadt; users at racket-lang.org
> Subject: RE: [racket] Limiting net-repl provided functions
> 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.

Ok, I see. In a way both are needed but for different purposes... which of
cource adds to the number of moving parts. At the moment, I'm advancing with
the sandbox approach.

> 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.

After adding some more modules to the test case, also Linux/ R 5.1 gave the
same error, except for the path:


br, jukka

> --
>           ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
>                     http://barzilay.org/                   Maze is Life!

Posted on the users mailing list.