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

On 2/20/07, support at taxupdate.com <support at taxupdate.com> wrote:
> Robby,
>
> On Tue, Feb 20, 2007 at 10:17:58AM -0600, Robby Findler wrote:
> > 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
> > namespace.
>
> I neglected to mention that in this case, I'm embedding mzscheme in a
> c++ environment.  I take it that either scheme_basic_env or
> scheme_make_namespace provides an isolated Scheme_Env/namespace for the
> untrusted code.

Sure, but it will probably be easier to do this on the Scheme side.
Take a look at the paper -- it has all of the relevant code.

> > 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
> > custodian-limit-memory.
>
> I tried this (in mzscheme3m) on a recent SVN snapshot:
>
> (define cust1 (make-custodian))
> (custodian-limit-memory cust1 1000 cust1)
> (current-custodian cust1)
> (let loop ((acc '()))
>     (loop (cons 'x acc)))
>
> I expected this to raise an exception after a few seconds, but it kept
> running.  What's the proper way to set this up?

I'm not sure what is wrong (Matthew will probably be able to tell us
when the sun is up on the other side of the globe.) I did notice that
there are 3 variations on 3m (from configure's --help output):

  --enable-account        3m: use memory-accounting GC (enabled by default)
  --enable-compact        3m: use compact GC (no accounting)
  --enable-backtrace      3m: support GC backtrace dumps

and I would have thought that the default one is the one that you
would want, but maybe something is wrong somewhere.

Sorry.

Robby