ocap violations: environ_get, random_get, and possibly clock_time_get

[erights]

Reported to me by @dckc . Resembles issues already discussed in a previous WASI meeting. Though I cannot find an issue recording the resolution of that discussion. Attn @sunfishcode @tschneidereit @linclark

At least the following

• __wasi_environ_get
• __wasi_random_get

are not conditioned on presentation of a capability, and so provide ambient authority to outside state.

I see that now

• __wasi_clock_time_get

does require an __wasi_clockid_t argument. However, this argument type is currently aliased to uint32_t. Is this a placeholder for a capability, waiting to be fixed once we have reference types? Is there a way to tell which types are placeholders for future capability types?

[sunfishcode]

Thanks for the report! This is being tracked in https://github.com/WebAssembly/WASI/issues/118.

The main question is how we should arrange for capabilities to be passed into applications. We have a few possible approaches, such as extending the preopen system, or using the interface types system currently under development to describe program interfaces.

To answer your question about types, the witx interface language now has a dedicated handle tyhpe which allows us to indicate the semantics of resource handles, regardless of how they're actually implemented.