I wonder if the unit system, or something like it, could be a basis for implementing this, especially the aspect of avoiding too much explicit argument passing.
Signatures can define bundles of identifiers, like file IO primitives. This lets you avoid having to know which specific primitives are being used, as long as they're collected in groups with the same security implications (e.g. `call-with-input-file` and `open-input-file` are probably equivalent). The untrusted `#lang dungeon` module could see the specifications for these identifiers without having access to the values/implementations: it would define and provide a unit importing (in the `racket/unit` sense) the signatures for the capabilities it needs. The more-trusted module invoking the `#lang dungeon` unit would have to link it with a unit supplying the needed capabilities, either from the root environment or by importing those capabilities (or stronger ones) in itself. The unit system also supports things like deriving restricted versions of a signature's values that obey the same specification. Probably you would want to build some scaffolding over `racket/unit` specific to ocap security, and a caveat in all of this is that my understanding of ocap security isn't especially deep. But what you describe sounds like dynamic linking, which is what units are designed for. I would start by looking in that direction before trying to interpose on the module registry: modules are basically designed for first-order, static linking. -Philip On Sun, Jul 14, 2019 at 3:29 PM Christopher Lemmer Webber < cweb...@dustycloud.org> wrote: > ra...@airmail.cc writes: > > > There is http://shill.seas.harvard.edu/ it runs on freebsd. > > Yes, it's a good source of inspiration. However it's really meant for > shell scripting and isn't quite a good fit for the case I need, which is > for more general racket programming. > > -- > 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. > To view this discussion on the web visit > https://groups.google.com/d/msgid/racket-users/87r26sqp8x.fsf%40dustycloud.org > . > For more options, visit https://groups.google.com/d/optout. > -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-users/CAH3z3gYWS7w02UaQ%2BWNbX4gMhQrzs-B_vLjmg-tMHGW7z4EKcg%40mail.gmail.com.