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.

Reply via email to