[plt-scheme] (in)security in a top-level eval

From: Robby Findler (robby at cs.uchicago.edu)
Date: Tue Feb 20 11:17:58 EST 2007

The top-level shouldn't cause you any problems. Just create a new
namespace for the eval'd code and it will only be able to use that

You will probably want to make a separate thread (and eventspace if in
mred) in case the code runs forever. To protect against code that
attempts to allocate all of the memory in your program, use

If you want to run more than one program, or make sure that the the
program  doesn't open too many files (or create too many threads) use
a custodian to clean up after it.

All of these things are being used in drscheme to protect it against
buggy/malicious code being evaluated at the REPL. You can read more
about that here: http://www.ccs.neu.edu/scheme/pubs/icfp99-ffkf.pdf

Note that that paper was written at a time before we had the GC
technology to do custodian-limit-memory. Now we do, but it requires
you to use the 3m collector. That collector is the default in the
nightly & SVN builds, but not in the latest official release.


On 2/20/07, support at taxupdate.com <support at taxupdate.com> wrote:
> I'm developing a program which includes eval's on user-generated code.  Before
> getting too far down this road, I'd like to be clear on the security issues.
> Currently, I enclose user code within a security guard that should prevent file
> writes and network access.  But the code is eval'ed at the top level, so I'm
> wondering what type of concerns this brings up.  Any guidance?
> Wayne
> _________________________________________________
>   For list-related administrative tasks:
>   http://list.cs.brown.edu/mailman/listinfo/plt-scheme

Posted on the users mailing list.