20 minutes ago, Matthias Felleisen wrote:
>
> On Jan 14, 2012, at 9:45 PM, Eli Barzilay wrote:
>
> > 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?
>
> That sounds an awful lot like stack inspection a la Java -- Matthias
Yes, but it's different in that it's based on a parameter that several
functions can do, rather than rely on the function's identity. (But
all of these things are similar in the same way, I think.)
20 minutes ago, Robby Findler wrote:
> The parameter solution sounds right to me and the sandbox does sound
> like the right level to put that.
The sandbox shouldn't be the place for that -- it would be a reversed
dependency, where the setup (core) code depends on a library. But in
this case it's not only a "shoudln't" -- it's a "cannot": see the
comment at the top of "setup/private/main-collects.rkt" about why it
shouldn't depend on anything.
But it would also not be right to just add some parameter to the
main-collects code, since that would be visible and usable by any code
to bypass security checks.
A few minutes ago, Robby Findler wrote:
>
> I think the way to think about this is as a capability mechanism.
> The capability is the key for the continuation mark and it grants
> you the ability to do certain things and is exposed/controlled via
> our usual module and scoping setup.
(Isn't that exactly what parameters (or more generally continuation
marks) do?)
> So, unlike in Java where an IO operation looks up the stack to see
> if it recognizes who called it, here it just says "is the key
> there?".
Yeah, that's what I think makes it better.
--
((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
