Allow modules to optionally import nothing at all

[cmcaine]

See: https://discourse.julialang.org/t/even-more-bare-baremodule/56156/

A module that imports nothing at all can be used to build a sandbox. Sandboxes are useful for defining smaller teaching languages (see Racket and the HTDP2e book) and, if they can be made secure, for evaluating untrusted code in a capability programming paradigm.

This commit changes the API of libjulia:

Old:

JL_DLLEXPORT jl_value_t *jl_f_new_module(jl_sym_t *name, uint8_t std_imports)

New:

JL_DLLEXPORT jl_value_t *jl_f_new_module(jl_sym_t *name, uint8_t std_imports, uint8_t using_core)

With thanks to Simeon Schaub and Mason Protter.

Questions for triage:

• Okay to change the libjulia API or would you rather I added a new function?

I came up with slightly better docs, too, but to save CI energy I haven't pushed them yet. But if anyone wants to bikeshed the docs, here they are:

In NEWS.md:

• Module(:name, false, false) can be used to create a module that does not import Base or Core. ([Allow modules to optionally import nothing at all #40110])

In doc/src/manual/modules.md:

If modules that contain no imports at all are needed, they can be defined with Mod = Module(:Mod, false, false). Code can be evaluated in them with @eval or Core.eval.

[JeffBezanson]

We might want to omit this as well, just so you can get a truly truly empty module.

[JeffBezanson]

Triage seconds this.

[JeffBezanson]

And then I guess using_core should be renamed default_names or something like that? Maybe not important.

[JeffBezanson]

Here's one of probably many ways to escape the sandbox:

t(x::T) where T = T
t(1).name.module # gives you Core

[simeonschaub]

Do we want to put this into julia.h as well?

[vtjnash]

Yeah, this'll never be an actual approach to making a sandbox (for example, you can also use ccall, various expressions that lower to top calls or constants, or simply call using), but not necessarily a reason to avoid this.

Also, ref #39114

[JeffBezanson]

If we wanted to gradually strengthen the sandbox, probably the next step is to make all identifiers that come from syntax (e.g. a.b => getproperty) lexically-scoped, i.e. lower them to __getproperty__ instead of Base.getproperty. Then you could e.g. inject a definition that disallows accessing some fields. I would kind of like to be able to do that anyway, though of course it's only one more brick in the sandbox wall.

[cmcaine]

Thanks for the review, everyone!

Perhaps I should have been clearer in the first post, I don't think that this feature on its own makes a sandbox, this is just part of what you'd need to do it nicely.

You can see my experiments in the discourse thread linked at the top and in https://github.com/cmcaine/Sandboxes.jl

The strategy I'm using there takes an Expr and rewrites it to be safe (or just errors). That covers most of @vtjnash's issues (I don't yet rewrite GlobalRefs, but that's possible with this approach, and I wrote code to control what literals can be created (in the discourse thread), too).

I think rewriting a.b to use a custom getproperty is a good idea too, I was looking at doing that to start with, but was able to catch everything I knew about without it, but I didn't know DataTypes have name.module! I can prototype that in Sandboxes.jl :)

[cmcaine]

I think it's a bit weird that we allow users to say yes to std_imports and no to default_names. It works, but I just don't think users will ever want that, so it might be confusing.

Perhaps a better interface would be to accept a symbol or enum or something as the second argument, at least on the Julia side?

function Module(name::Symbol, type::Symbol)
    if type == :module ...
    elseif type == :baremodule ...
    elseif type == :emptymodule ...
    else error()
    end
end

?

Edit: Jeff suggested passing nothing to std_imports, which also makes sense to me, I think I'll do that.

[simeonschaub]

Since this is a pretty internal method, I think it's fine to just have two boolean arguments. I don't really have strong opinions on how to name this option.

[Acmion]

I see some use cases for applying the proposed import rules to the Main module as well.

While this is not directly related to this pull request, it is something that could be considered for the future.

[DilumAluthge]

@simeonschaub CI is all green now. Is this good to merge?

[simeonschaub]

Thanks @cmcaine for the contribution! Sorry it took so long to get merged.