[racket] Handin Server + PLAI problem [and 1 more messages] [and 2 more messages]

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!