On Sat, Jan 14, 2012 at 9:23 PM, Eli Barzilay <e...@barzilay.org> wrote: > 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.
I think that security-guards and continuation marks are a good way to build a high-level capability permissions model in Racket. I would have thought that the sandbox would be a good library to include that in, but maybe we should be doing something smaller that the sandbox just uses? (Is that what you're saying?) Robby ____________________ Racket Users list: http://lists.racket-lang.org/users
