Make wasmedge preopen the container root

[jprendes]

With #78 we inadvertedly stopped preopening the container root.
This means that the wasmedge shim doesn't have access to the container filesystem.
This PR reintroduces preopening the container root with wasmedge.

[devigned]

In the long run, pre-opening anything may be a bad (default) choice. We need to think about how pre-opens and other access / capabilities should be described.

[jprendes]

This is preopening the container root, not the host root.
@devigned what use case(s) did you have in mind for configuring preopening?

[devigned]

My comment is not about container or host fs. It's more that by default many runtimes do not enable fs access unless specified; fs access is off by default. We are defaulting the root container fs to be pre-opened for convenience of the user. Some users may not want to have any fs access at all.

I'm just calling this out to bring it to attention of the broader audience. As for this PR, I think we should continue to pre-open. However, we may want to rethink this in the future.

[devigned]

lgtm

[jprendes]

It's a valid point that we should consider.
I'm just struggling to understand the use case. I woud imagine that if you don't want fs access you just don't include any file in your image root (except your wasm file, until we move that to artifacts). Am I missing something?

[devigned]

It's application of least privileges (capabilities) for Wasm. For example, you might run some untrusted, 3rd party Wasm app, and want the runtime sandbox to not provide access to the fs.