It seems that a typed module needs to be as *protected* as TR itself,
but not as *powerful* (or privileged) as TR. Otherwise one could define
a malicious typed module that uses the power TR grants it to break
sandboxing. Is the combination of protected but not powerful possible in
the current system?
A module's declaration inspector gives power, since a module can get it
using variable-reference->module-declaration-inspector. That power can
be converted into protection via syntax-arm, etc. The inspector
associated with a module's invocation gives protection, since it
controls module->namespace. So the solution would be setting the
declaration inspector to be weak and the invocation inspectors to be
strong, but that's backwards from the way Racket currently creates
invocation inspectors, and it seems like changing it might break things
like protect-out.
Ryan
On 07/18/2016 11:59 PM, Matthew Flatt wrote:
That sounds like a promising direction.
A declaration that means specifically "more powerful inspector" isn't
quite right, because there's usually not a more powerful inspector
available (which is why you can use `ffi/unsafe` in a program run by
DrRacket). Probably you want to say "at least as powerful as X", where
"X" corresponds to TR's own capability --- and that capability is
already reflected by the inspector associated with syntax objects to
gain access to unsafe operations. Using the inspector associated with a
`#%declare` keyword (in its syntax-object form) seems unusual, but
maybe it would work.
At Mon, 18 Jul 2016 23:05:30 -0400, Sam Tobin-Hochstadt wrote:
What about a `#%declare` form that prevented access to the underlying
namespace, except with a more-powerful inspector (such as the one
DrRacket has to set up the REPL)?
Sam
On Mon, Jul 18, 2016 at 10:58 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
Ah, ok. An inspector prevents a sandbox from getting the namespace of a
TR module that was created outside the sandbox (in the same way that it
prevents access to `ffi/unsafe` as defined outside the sandbox), but it
doesn't prevent access to the namespace of a module defined inside the
sandbox.
I don't immediately see the solution. I don't think making `eval`
always add `#%top-interaction` would not solve the problem, because
`#%top-interaction` could be redefined or gotten around by other
reflective operations.
--
You received this message because you are subscribed to the Google Groups "Racket
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
