Decide whether inheriting all environment variables is the right model

[Achille]

During the early development of the project, we chose to automatically inherit the environment of the host in guest processes to simplify configuration and have a default that would serve well for fast iteration over the project development.

Now that the project matures, we may want to revisit those early design decisions.

• Inheriting the environment may be a security risk, especially when executing processes to handle asynchronous tasks in scenarios where the code may come from a third party

• There is a relationship between #152 and the notion of a working directory; guest languages such as Go use the PWD environment variable to determine the current working directory and emulate the functionality which typically belongs to the operating system; timecraft could automatically set this variable to the value of the current working directory (see dispatchrun/wasi-go#78 for related context as well)

[Chris O'Hara]

For a nice balance of convenience and security, maybe the root process inherits the environment and disk access, but sub-processes that are spawned implicitly to handle tasks do not? The user can opt-out of the default root process access, and opt-in (via application code to spawn tasks) to passing environment variables and exposing parts of the file system?

[Achille]

This seems like a good model to try out 👍