[racket] Sandbox needs to access preferences? Why?

From: Robby Findler (robby at eecs.northwestern.edu)
Date: Mon Apr 2 13:11:56 EDT 2012

On Wed, Mar 14, 2012 at 2:39 AM, Jordan Johnson <jmj at fellowhuman.com> wrote:
> On Mar 13, 2012, at 1:48 PM, Robby Findler wrote:
>> Do you get a stacktrace with the error?
> No -- since errors are being caught by the handin server, I assume -- but I've narrowed it down a bit by now and can offer some more specifics:  In
>           (parameterize ([sandbox-namespace-specs
>                           (list make-base-namespace 'hw/solutions)])
>              ...create two evaluators...)
> I was neglecting to include '2htdp/image in the namespace specs list, and adding it eliminated the error message about accessing preferences.

This is fairly mysterious to me. It sounds like some error message
rendering is trying to use the prefs, which seems unfortunate.

If there is a way to get a stracktrace (Eli?), then that would be a
help. The only other thing I can think of doing is to replicate your
setup and start poking around in it.

>  I also found, in experimenting, that
>        * creating either one of the two evaluators alone is sufficient to trigger the error -- make-evaluator/submission and make-module-evaluator behave the same in this regard.
>        * it does not matter whether '2htdp/image is included in the allow-read list passed to either of the make-evaluator functions.
> In any case, I seem to have found my fix for the moment, but if I can help you track down where that obscure error message originated and why, let me know and I'll be glad to.
> Incidentally, separate from the concern of my initial post: In the body of that (parameterize ...) expression, I found i have to create the second evaluator thus:
>  (make-module-evaluator (build-path asg-dir "solution.rkt") #:allow-read '(hw/solutions))
> where hw is a collection I have linked to a directory (via raco link).  If I omit the #:allow-read as I did originally (quoted below), I get this error in the server log and via the client UI:
>  ERROR: file-exists?: `exists' access denied for /<path to hw collection>/solutions.rkt
> I would rather not expose my system pathnames to the end users, so I assume the best way is to catch this kind of error explicitly in the code that creates the evaluators.  (In addition to doing the right thing by including the #:allow-read, of course; I realized, while testing, that the student can trigger this message if they (require...) my library name from their file.)  Does that sound about right?

I don't see any non-hacky solutions. But you could catch errors and
check to see if you see sensitive paths in the error message and then
redact them.


Posted on the users mailing list.