Thanks for the pointer, Scott! I had been slowly coming to the conclusion I was going to need to define a #lang, and I'd even run across your paper, though I was holding out hope that there was some kind of shortcut for code running in a sandbox. I definitely like the idea of being able to use "regular" objects, and locking things down with a custom language means I'm also less likely to get bitten by future changes to Racket the way changes to Python made rexec stop working.
I think I may still want to stick with having "classes" be modules, because that makes code replacement much easier to reason about. But if I can force everything that can be referenced from a module variable to be immutable and disallow anything that could modify the namespace after loading the module, it seems like I should be able to share a single namespace among all instances of a given class. Time for me to go code up a proof-of-concept. On Wed, Aug 19, 2015 at 10:05 AM Scott Moore <sdmo...@fas.harvard.edu> wrote: > Hi Sean, > > An alternative approach you might consider instead of relying heavily on > sandboxes and namespaces is to define your own #lang where you can > carefully control how different objects are allowed to communicate with > each other. This approach could have two advantages: > 1) you can use lighter-weight mechanisms to represent objects, and > 2) you can restrict things to make it much less likely that you would get > bitten by a misunderstanding how namespaces and require, etc, work. > > We used a similar approach when writing Shill, our capability-based shell > scripting language based on Racket (shill-lang.org). You can find a short > description of how we did this in section 3.1 of the paper ( > http://shill.seas.harvard.edu/shill-osdi-2014.pdf). > > Cheers, > Scott > > On Tue, Aug 18, 2015 at 12:48 AM, Sean Lynch <se...@literati.org> wrote: > >> Hi, folks. I'd like to implement an LPMUD-like multi-user programmable >> environment in Racket. The idea is that an "object" would be a module plus >> some state, similar to a gen_server in Erlang. Objects would each live in >> their own sandbox and communicate with one another via message passing, >> probably via channels. >> >> So far so good; despite my inexperience with Racket, I am fairly certain >> this should be straightforward to implement. And a sandbox per persistent >> object and message passing between them doesn't seem like it would be too >> high a price to pay, since this is what Erlang does, and it's similar to >> what LPMUD and MOO and Genesis do. >> >> However, users nee to be able to extend and reuse one another's code, and >> I'd like them to be able to do that without having to trust the code not to >> leak private state or affect their own code's behavior in unexpected ways. >> It seems like I can use contracts to some extent to help users from >> accidentally passing or returning excessively powerful capabilities >> (however I implement those: proxies, closures, etc); But at the very least >> I know that any function called in a "require"d module can inspect and >> modify the current namespace, which will affect dynamic code even if it >> doesn't affect module code. And I imagine there are probably other >> introspection functions that could enable access at least to any state >> stored in top-level variables. >> >> So my question is: assuming it is even practical to protect state from >> code in "require"d modules running in the same sandbox, what would be the >> best way to go about this? Or are sandboxes and channels (or some other way >> to pass messages between sandboxes) cheap enough that that's the best way? >> > -- >> 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 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=BQMFaQ&c=WO-RGvefibhHBZq3fL85hQ&r=OPR-Xys5wfSBIeTkWaH0D_htBR-X7qY24pTHU6ib2iM&m=vNTo0BhTaa0rf5fiErRpax-tpq3uFcfyQMrQ0pZ_dcc&s=xIiHlc9nqPBTsx6n-KUJPsWMGd6iTGjpZyp6arDHCJo&e=> >> . >> > -- 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.
