Open nicowilliams opened 9 years ago
This will require binding builtins sans I/O to modules, then binding all builtins to the main program.
This in turn will also require that we treat builtins as a module that is imported into the global namespace.
It should be possible for top-level programs to allow imported modules to get I/O builtins and eval
.
This means that modules not permitted to have direct access to I/O should get stubs that error
out.
Modules could be trusted/not-trusted, and get/not-get builtins that have side-effects.
Today the main builtins to deny to untrusted modules would be
input
andinputs
, since they can steal the main program's inputs. In the future we'll want to deny untrusted modules any way to open arbitrary files (import "file" as $foo;
is OK: it can only be used to read JSON files in the module library, and the filename has to be a constant).This means that there will be no need to have new command-line arguments with which to express constraints on what a program can do: the main program could do anything; the modules could only waste cycles (and play games with timing). Well, a single option to deny an untrusted program access to side-effect-having builtins would be fine.