An hour ago, Robby Findler wrote:
> On Sat, Jan 14, 2012 at 7:04 PM, Eli Barzilay <e...@barzilay.org> wrote:
> >
> > Following a reply from Matthias, I tried it in drr, and that does
> > have an offending exists, but looking at the stacktrace, there's a
> > `print-values' so it sounds like the drr-installed printer -- ?
>
> I don't think this is relevant. I'm not running the handin server
> from inside drracket and I doubt John is either.
(I know -- I thought that you might have noticed a problem that is
therefore irrelevant.)
An hour ago, Robby Findler wrote:
> When I set up the modules below, I get these two stacktraces for
> what seem to be thinks the sandbox would reject:
>
> [robby@yanpu] ~$ racket ~/tmp.rkt
> security guard: current-directory #<path:/Users/robby/> (exists)
> (#f . #(struct:srcloc #<path:/Users/robby/tmp.rkt> 9 17 283 475))
> (find-main-collects . #(struct:srcloc
> #<path:/Users/robby/git/plt/collects/setup/private/main-collects.rkt>
> 19 4 817 884))
Oh, then this makes the offender clear, no? In the above function I
see at least three pieces that can lead to such access: two uses of
`find-executable-path', and the last `simplify-path' (that defaults to
allow FS access).
I still don't think that this should be resolved by the sandbox though
-- doing this means that it needs to figure out what permissions are
needed backwards from that code. Instead, I think that this code
should be explicitly allowed -- but I don't have a good idea on how
that can be done. Maybe it should always work with some unrestricted
guard? (Sounds like a dangerous idea.) Or maybe some private
parameter (or continuation mark) that can be used to identify "I'm now
in blessed code" which the sandbox security guard can check and if in
that case avoid the restrictions?
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
____________________
Racket Users list:
http://lists.racket-lang.org/users
